Mysql – Automatically purging binlogs after successful replication

MySQLreplication

I have a dedicated server hosting a MySQL database, and want to use replication to have an always up-to-date backup somewhere.

I chose to use Amazon RDS as my replica, and I'm following this guide:

Replication with a MySQL Instance Running External to Amazon RDS

What I fail to understand however, is who/what is supposed to take care of purging binary logs. The only configuration I found is expire_logs_days, which the documentation describes as:

You can also set the expire_logs_days system variable to expire binary log files automatically after a given number of days (…). If you are using replication, you should set the variable no lower than the maximum number of days your slaves might lag behind the master.

Is this the standard procedure DBAs use?

Isn't it possible to have RDS, which is the only replica, purge the logs on the master as soon as it's processed them?

Best Answer

Server is responsible to purge their own file. Guess what happens if your master has two slaves and one of it catches up faster deleting logs required for second?!!

So yes expire_logs_days is the way to go. Set that value wisely and let master do its business.

That said why do you want to purge logs? You have purge binary logs to command but I'd still let purging upto master unless disk is critical.

If you want it, then you can script out the manual purging logic: Check all slaves have caught up to latest Purge a logs before the exec_master_log_file.

In my opinion this is absolutely unnecessary unless there some odd requirement that u just can't think about...

SLAVE

If your Slaves are not Masters, then Slaves do not need binary logging at all. You can put a cap on the amount of relay log space accumulated by a Slave. In order to throttle relay logs at 4G, add relay_log_space_limit to /etc/my/.cnf on every Slave

[mysqld]
relay_log_space_limit=4G

and restart mysql

If you cannot set this, at least you should have some kind of alerting that does SHOW SLAVE STATUS\G and check the value of Relay_Log_Space (total bytes consumed by relay logs).

MASTER

As for the Master, you could set expire_logs_days to 1, but there is a severe warning I have for you...

If replication breaks, you have 1 day to fix it. Otherwise, a binary log on the Master may rotate away and you cannot run any CHANGE MASTER TO command to realign replication. I would leave expire_logs_days at 3 on the Master.

SUGGESTION #1

If you have any overnight bulk processing to do, maybe should run the bulk processes on on the Master with SET SQL_LOG_BIN=0; at the Start of the Session. This, of course, will not replicate to the Slave. You can perform the Same Bulk Load in Parallel to both Slaves.

SUGGESTION #2

Another thing you could do to manage the Master binary logs accumulation is this.

Run SHOW SLAVE STATUS\G on both Slaves. Look at Relay_Master_Log_File. That represents the binary log on the Master whose last command was executed on the Slave.

*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: 10.4.92.250
                Master_User: replicant
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.009677
        Read_Master_Log_Pos: 855227755
             Relay_Log_File: relay-bin.000674
              Relay_Log_Pos: 757296783
      Relay_Master_Log_File: mysql-bin.009590
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB:
        Replicate_Ignore_DB:
         Replicate_Do_Table:
     Replicate_Ignore_Table:
    Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
                 Last_Errno: 0
                 Last_Error:
               Skip_Counter: 0
        Exec_Master_Log_Pos: 757296646
            Relay_Log_Space: 94274010765
            Until_Condition: None
             Until_Log_File:
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File:
         Master_SSL_CA_Path:
            Master_SSL_Cert:
          Master_SSL_Cipher:
             Master_SSL_Key:
      Seconds_Behind_Master: 80561
1 row in set (0.00 sec)

In this example, Relay_Master_Log_File is mysql-bin.009590. All binary logs before this one can be removed from Master. You could run this on the Master:

PURGE BINARY LOGS TO 'mysql-bin.009590';

This will erase older logs and still leave replication in tact.

CAVEAT

Binary Logs are files that serially compiles (like a FIFO queue) all completed SQL transactions as either a SQL statement or a row change. A relay log is a file that collects binary log entries from a remote server (aka Master).

In MySQL Replication

Master must have its binary logs enabled
Slave compiles relay logs
When all SQL in a relay log is processed, it is deleted
On a Slave, when there is more that one relay log on a DB Server, it may indicate replication is falling behind because the IO thread is collecting SQL from a Master faster that the SQL thread can process the relay logs.
Using relay_log_space_limit prevents replication from piling up and potentially filling up a disk. Relay logs rotate out based on rule #3
It is possible for a DB Server to be both a Master and Slave. That's the only circumstance under which a Slave must have binary logs enabled. In that scenario, a DB Server will have both Binary Logs and Relay Logs.

If you failover to a Slave, and you want to Make it a Master

service mysql stop
Add log-bin=mysql-bin to /etc/my.cnf on the Slave
service mysql start

You will have to setup replication of other Slaves to the newly promoted Master and make sure the data on the Slave match up with the newly promoted Master

UPDATE 2012-08-13 17:47 EDT

According to the MySQL Documentation on relay-log option, you should define it. Here is why:

Due to the manner in which MySQL parses server options, if you specify this option, you must supply a value; the default basename is used only if the option is not actually specified. If you use the --relay-log option without specifying a value, unexpected behavior is likely to result; this behavior depends on the other options used, the order in which they are specified, and whether they are specified on the command line or in an option file. For more information about how MySQL handles server options, see Section 4.2.3, “Specifying Program Options”.

MySQL: Does Amazon’s RDS Multi-AZ feature use binary logs

Yes it does uses mysql binary logs for Multi-AZ replication.

Here this FAQ at amazon site confirms this:

Q: Can I directly access the binary logs for my Database Instance to manage my own replication?
A. Amazon RDS does not currently provide access to the binary logs for your Database Instance.

http://aws.amazon.com/rds/faqs/#103

And this one too.

You may find in some cases that your Read Replica(s) aren’t able to receive or apply updates from their source Multi-AZ DB Instance after a Mulit-AZ failover. This is because some MySQL binlog events were not flushed to disk at the time of the failover. After the failover, the Read Replica may ask for binlogs from the source that it doesn’t have. This loss of MySQL binlogs during a crash is described in the MySQL document here.

http://aws.amazon.com/rds/faqs/#107

This simply confirms that it does uses binary logs.