<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Binary Log on FromDual GmbH</title><link>https://www.fromdual.com/tags/binary-log/</link><description>Recent content in Binary Log on FromDual GmbH</description><generator>Hugo</generator><language>en-GB</language><managingEditor>oli.sennhauser@fromdual.com (Oli Sennhauser)</managingEditor><webMaster>oli.sennhauser@fromdual.com (Oli Sennhauser)</webMaster><copyright>© FromDual GmbH</copyright><lastBuildDate>Tue, 26 Mar 2024 09:11:05 +0000</lastBuildDate><atom:link href="https://www.fromdual.com/tags/binary-log/index.xml" rel="self" type="application/rss+xml"/><item><title>Traffic mirroring with MariaDB MaxScale</title><link>https://www.fromdual.com/blog/traffic-mirroring-with-mariadb-maxscale/</link><pubDate>Thu, 24 Dec 2020 16:27:33 +0000</pubDate><author>oli.sennhauser@fromdual.com (Oli Sennhauser)</author><guid>https://www.fromdual.com/blog/traffic-mirroring-with-mariadb-maxscale/</guid><description>&lt;p&gt;Recently we had the case that a customer claimed that MariaDB 10.3 Binary Log is using 150% more space on disk than MySQL 5.7 Binary Log. Because I never observed something similar, but to be honest, I did not look to intensively for this situation, we had to do some clarifications.&lt;/p&gt;</description></item><item><title>MySQL replication with filtering is dangerous</title><link>https://www.fromdual.com/blog/mysql-replication-with-filtering-is-dangerous/</link><pubDate>Thu, 12 Jan 2017 16:47:53 +0000</pubDate><author>oli.sennhauser@fromdual.com (Oli Sennhauser)</author><guid>https://www.fromdual.com/blog/mysql-replication-with-filtering-is-dangerous/</guid><description>&lt;p&gt;From time to time we see in customer engagements that MySQL Master/Slave replication is set-up doing schema or table level replication filtering. This can be done either on Master or on Slave. If filtering is done on the Master (by the &lt;code&gt;binlog_{do|ignore}_db&lt;/code&gt; settings), the binary log becomes incomplete and cannot be used for a proper Point-in-Time-Recovery. Therefore FromDual recommends AGAINST this approach.&lt;/p&gt;</description></item><item><title>Binlog format MIXED with filtering</title><link>https://www.fromdual.com/blog/binlog-format-mixed-with-filtering/</link><pubDate>Wed, 15 Jul 2015 06:11:36 +0000</pubDate><author>oli.sennhauser@fromdual.com (Oli Sennhauser)</author><guid>https://www.fromdual.com/blog/binlog-format-mixed-with-filtering/</guid><description>&lt;p&gt;Binlog format &lt;code&gt;MIXED&lt;/code&gt; changes the binary log format (&lt;code&gt;ROW&lt;/code&gt; or &lt;code&gt;STATEMENT&lt;/code&gt;) depending on the queries (deterministic or not). This makes it impossible to define 100% correctly working binary log filter rules.&lt;/p&gt;</description></item><item><title>Oops! - That SQL Query was not intended... Flashback</title><link>https://www.fromdual.com/blog/oops-that-sql-query-was-not-intended-flashback/</link><pubDate>Mon, 24 Jun 2019 14:12:00 +0200</pubDate><author>oli.sennhauser@fromdual.com (Oli Sennhauser)</author><guid>https://www.fromdual.com/blog/oops-that-sql-query-was-not-intended-flashback/</guid><description>&lt;p&gt;It is Saturday night at 23:19. Time to go to bed after a hard migration day. Just a last clean-up query before finishing: Tap tap tap. Enter! - Oops!&lt;/p&gt;</description></item></channel></rss>