[ClusterLabs] Mysql M/S, binlogs - how to delete them safely without failing over first?

Andrei Borzenkov arvidjaar at gmail.com
Tue Aug 18 23:49:26 EDT 2015

19.08.2015 00:19, Attila Megyeri пишет:
> Hi List,
> We are using M/S replication in a couple of clusters, and there is an issue that has been causing headaches for me for quite some time.
> My problem comes from the fact that binlog files grow very quickly on both the Master and Slave nodes.
> Let's assume, that node 1 is the master - it logs all operations to binlog.
> Node 2 is the slave, it replicates everything properly. (It is strange, however, that node2 must also generate and keep binlog files while it is a slave, but let's assume that this is by design).
> There are ways to configure mysql to keep the binlog files only for some time, e.g. 10 days, but I had an issue with this:
> To explain the issue, please consider the following case:
> Let's say that both node1 and node2 are up-to-date, and we did a failover test on day 0.
> DB1 is the master, DB2 is the slave.
> DB1 has master position "A", DB1 has master position "B".
> After 20 days, lots of binlog files exist on both servers, I would like to get rid of them, as the slave is up-to-date.
> I decide to delete all binlog files older than 1 day by issuing "purge binary logs...".
> I try to fail over so that DB2 becomes the master, but DB1 tries to connect to DB2 for replication and wants to replicate starting from a position that it "remembers" from the times when DB2 was the master, and starts to look for some binlog files that are 20 days old. Now, the issue is, that those old binlog files have been deleted since, and replication stops with error (cannot find binlogs).
> Am I doing something wrong here, or is something configured badly?

If I read mysql agent code correctly it stores current log position only 
when promoting instance.

> OR am I assuming correctly that in order to purge the binlog files from both servers I need to make a failover first?

This should reset log position, as failover would promote new instance 
and so I expect it will set new value.

More information about the Users mailing list