Retain your MySQL Binary Logs until needed – but no longer (using Zmanda Recovery Manager)

ZRM for MySQL requires binary logging to be enabled on the MySQL server to do incremental backups. Enabling binary logs has minimal impact on MySQL performance. But, in an active database, the binary logs can grow to hundreds of gigabytes or even terabytes.

ZRM of MySQL has multiple plugin interfaces to customize the backup and recovery process to user environment. One of the plugin interfaces is the post backup plugin. The binary logs are no longer required after a backup. The post backup plugin can purge the binary logs after the backup. This will allow the system administrators to balance between the need for incremental backups as well as the storage needs for the logs.

The following command that purges the old binary logs can be added to the default post backup plugin for ZRM for MySQL.

mysql -uroot -ppasswd -e “purge master logs before date_sub(now(), interval 1 day);”

Other option is to set “expire_log_days” MySQL server parameter. The default values for expire_log_days is not to purge logs.

Caution: Users must be careful in purging binary logs on the master replication server if backups are being done on the master server. If slaves are lagging behind the server more than a day, the binary log purge will cause replication to fail.

Comments are closed.