Description:
When writing binlogs, usually for replication, but also for point in time recovery, there is an option to expire after the logs are a certain age (in days), but no option to expire if the used size is larger than a predetermined amount. More flexibility with the configuration settings would mean that a sudden change in workload might not fill up a disk as can happen now if you do not monitor the server correctly.
When a slave writes relaylogs and if it is a long way behind a similar issue can happen. There is a configuration variable relay_log_space_limit, (http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_relay_log_space...), but that setting is not dynamic and so it loses all it's use
as a sudden need to adjust this setting can not be done without bouncing mysqld.
How to repeat:
Notice that for binlogs you can only configure expiry in whole units of a day.
Notice that for relay logs you can configure a maximum size but that size is not configurable dynamically.
Suggested fix:
I'd like to see a "maximum space" setting for both binlogs and relaylogs (different configuration variables) which is dynamic and thus allows better control of disk space than is now possible. Also the expire_logs_days on some servers is too course as a server that writes a large amount of binlogs may benefit from a non-integer value, such as 1.5 or 2.5 or 0.2 etc. I'd like to see the setting changed so that a smaller unit can be specified. Given the variable's name it seems wiser to just accept a decimal value.
Allowing more flexibility where will prevent more situations where manual intervention is needed, usually when the database server workload has changed and this is causing a sudden spike in writes of binlogs, or relay logs.
