2

I've read the docs saying log_slave_updates is required. It makes sense for a general promotion situation.

But is that really still required for something you're intending to be a read only slave that will never get promoted?

3

Yes, you must set it when using gtid, otherwise mysql won't start, providing you the following error:

[ERROR] --gtid-mode=ON or UPGRADE_STEP_1 or UPGRADE_STEP_2 requires 
--log-bin and --log-slave-updates

The slave requires its own executed binary logs in order to auto-position itself in the case of a stop (for example, if it crashes) or a master change (the hardware on the master fails without a possibility of a fix and another slave is promoted as the new slave), even if it is not going to be a master itself never. Although I suppose that can be controlled exclusively in-memory when running, I would bet it needs its own binary logs as a failsafe in case of a crash.

You may think that that is a lot of trouble, but it is a small burden in exchange for not having to deal with binlog files and binlog pos addresses anymore. Also, binary logs on the slave was always a good idea. You can still purge them automatically with expire-logs-days/max-binlog-size if the size is the problem. And with group-commit in 5.6, the performance penalty should be minimal. The other thing why I did not used log_slave_updates before (checking that no writes have been done on the slaves) can now be controlled with gtid_executed values.

In a nutshell, set it up, and do not worry on most cases.

| improve this answer | |
  • Just for anyone else who happens by here, for our workload log_slave_updates imposes a penalty of around 10% to replication performance, which could be a dealbreaker for some. – cbmanica Sep 20 '18 at 23:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.