Great post, thanks.

The documentation for both settings shows both as being non-dynamic?

As we’re running in Google Cloud and use XFS on the persistent disks, when we want to expand our disk sizes, we just do this on the fly with a couple of commands and no downtime.

If we were to set these two values on instance creation, when we came to expand our disks we would find that we were unable to make this additional capacity available to MySQL – binlog_space_limit and relay_log_space_limit would remain fixed with values that are no longer suitable.

Thanks

John

Is this parameter aware about what happens on slaves side?
For instrance, let assume that one or more slaves are stopped for some reason and the DML in the master binary logs are not been read by the slaves for a while. Then, if the master purges the old binary files as requested by binlog_space_limit value, to sync the stopped slaves , one must take a full backup in order to rebuild the slaves.
I know that could be a challenge on master side to discover if any of the slaves are stopped. Right ?

Thanks

Stofa.

This will help in cases where you have a lot of UPDATE or DELETE commands, but obviously workloads with mostly INSERT would not benefit.

Note that this setting may not be compatible with external replication tools or cases where you want to use a “flashback” type utility.