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?
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It only takes a minute to sign up.Sign up to join this community
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
In a nutshell, set it up, and do not worry on most cases.