Sunday, January 31, 2016

Why log_slave_updates is a bad default

In a recent post the MySQL product managers asked the community for feedback about proposed new defaults. One of the proposals is to make log-slave-updates on by default.

There are other important options that require some debate. They all look reasonable to me. This one, instead, which implies funnelling the replication events in a slave to its binary log, is questionable.

Let's start for the reason why it is a good idea. The scenario in which it makes sense is when you want a slave to be a master of one or more slaves. This is a common scenario in many cases where you need to support many servers in production. It is not, however always useful. I would like to show, here, a few cases when log-slaves-update is a problem rather than a solution.

Regular Master/Slave deployments

I would say that this case, rather than the hierarchical topology, is the most common situation. When you have a master/slave topology, you want the slave to be ready to replace the master, and for this you don't need log-slave-updates. Also the manual recommends having a slave without log-slave-updates when your goal is to switch roles after a failover.

When using multi-source replication

In multi-source replication, you can have more than one topology. Unlike the ancient circular replication, which was the only way of implementing multi source replication prior to MySQL 5.7, and has proven to be inefficient, the new methods for multi source don't need to enable log-slave-update, unless you are using complex and hybrid topologies like a star or a composite topology. Having used and tested such methods with MySQL and Tungsten replication for years, I can tell confidently that having a direct node-to-node replication stream is always preferable to using an intermediate node: there is better performance, less risk of data muddling, more certainty about the data origin.

Whenever you need performance in the slave

If we are not dealing with a hierarchical topology, having log-slave-updates means that the slave has a penalty performance for no good reason.

Suggesting a better improvement than the intended default

Rather than making log-slave-update the default, what I would like to see in the next MySQL version is a mechanism for log servers, i.e. an intermediate node that receives binary logs from a master and serves them to the slaves without need of applying anything. If hierarchical topologies are so important, this should be the way to go, rather than stretching an obsolete technology beyond its capabilities.

4 comments:

Morgan Tocker said...

Thanks Giuseppe! Good feedback.

AndreiElkin said...

Giuseppe,

> Rather than making log-slave-update the default, what I would like to see in the next MySQL version is a mechanism for
> log servers

Proxy master, why not...
In fact that extends semantic of --log-slave-update currently having two choices of execute-and-log and execute-not-log with a third of log-not-execute.

Andrei Elkin, MySQL replication.

Mahesh Patil said...

You can say it as binlog server concept used in Booking.com http://blog.booking.com/mysql_slave_scaling_and_more.html

Yes this is a very good idea but need to simplify so that DBA's can take advantage of this feature.

Unknown said...

Thank you for the feedback! I just wanted to say thanks and let you know that we're listening. :) This input has sparked a number of internal discussions and actions.

Thanks again!