Bug #68236 Make binlog and relay sizes dynamically configurable by "maximum size"
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.
Portions of this website are copyright © 2001, 2002 The PHP Group
Page generated in 0.044 sec. using MySQL 8.4.7-u6-cloud
Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the
respective copyright holders.
It is not reviewed in advance
by Oracle and does not necessarily represent the opinion of
Oracle or any other party.