Replication - binary log auto removal after processing

[tech101]

Can I get the master (or slaves) to automatically remove the binary
logs once they are processed by all slaves?

It says in the mysql manual :
If you are using replication, you should not delete old binary log
files until you are sure that no slave still needs to use them. For
example, if your slaves never run more than three days behind, once a
day you can execute mysqladmin flush-logs on the master and then
remove any logs that are more than three days old. You can remove the
files manually, but it is preferable to use PURGE MASTER LOGS, which
also safely updates the binary log index file for you (and which can
take a date argument as of MySQL 4.1). See Section 13.6.1.1, "PURGE
MASTER LOGS Syntax".
http://dev.mysql.com/doc/refman/4.1/en/binary-log.html

This seems to suggest that you need to estimate an amount of time it
will take for all slaves to be up to date, or have processed all the
binary log files. If this is the case, how do you take into account
something going wrong with the slave/s by not deleting the binary logs
if this happens?

It seems like a better idea to just remove the binary logs when the
master has full evidence that all the slaves have correctly processed
them (I/O thread retrieved them)... is there a way to do this?

Thanks in advance!

[Gordon Burditt]

>Can I get the master (or slaves) to automatically remove the binary

>logs once they are processed by all slaves?

How does the master know about "all slaves"? This includes the one
you haven't finished building yet, and doesn't include the one that
caught fire last week and hasn't logged in since but nobody informed
MySQL that it was gone permanently (and there's no way to inform it)
since you decided not to replace it.

Oh, yes, just because a slave fetched a binary log file doesn't
mean it processed it or won't need it again. For example, let's
suppose that replication stopped because of some kind of error. It
stops. You reset the starting point beyond the offending record,
which I have observed deletes existing binary logs and when you
start up replication, it starts re-fetching them.

Also not ruled out is the possibility that a disk drive fails on a
slave, you replace the drive and restore a day-old backup, then
start up replication and it re-fetches a day's worth of logs.

Replication won't help you if someone executes a disastrous query
and your replication setup efficiently replicates the disaster
(sometimes this is a query that should have had a WHERE clause but
didn't) on all of your slaves. For that reason, keeping binary
logs since your last backup is a good idea even if replication never
gets that far behind.

>It says in the mysql manual :
If you are using replication, you should not delete old binary log
files until you are sure that no slave still needs to use them. For
example, if your slaves never run more than three days behind, once a
day you can execute mysqladmin flush-logs on the master and then
remove any logs that are more than three days old. You can remove the
files manually, but it is preferable to use PURGE MASTER LOGS, which
also safely updates the binary log index file for you (and which can
take a date argument as of MySQL 4.1). See Section 13.6.1.1, "PURGE
MASTER LOGS Syntax".
http://dev.mysql.com/doc/refman/4.1/en/binary-log.html

This seems to suggest that you need to estimate an amount of time it
will take for all slaves to be up to date, or have processed all the
binary log files. If this is the case, how do you take into account
something going wrong with the slave/s by not deleting the binary logs
if this happens?

It seems like a better idea to just remove the binary logs when the
master has full evidence that all the slaves have correctly processed
them (I/O thread retrieved them)... is there a way to do this?

The master doesn't have that kind of evidence.

[tech101]

On Apr 13, 9:38 am, gordonb.bm...@b urditt.org (Gordon Burditt) wrote:

Can I get the master (or slaves) to automatically remove the binary
logs once they are processed by all slaves?

How does the master know about "all slaves"? This includes the one
you haven't finished building yet, and doesn't include the one that
caught fire last week and hasn't logged in since but nobody informed
MySQL that it was gone permanently (and there's no way to inform it)
since you decided not to replace it.

Oh, yes, just because a slave fetched a binary log file doesn't
mean it processed it or won't need it again. For example, let's
suppose that replication stopped because of some kind of error. It
stops. You reset the starting point beyond the offending record,
which I have observed deletes existing binary logs and when you
start up replication, it starts re-fetching them.

Also not ruled out is the possibility that a disk drive fails on a
slave, you replace the drive and restore a day-old backup, then
start up replication and it re-fetches a day's worth of logs.

Replication won't help you if someone executes a disastrous query
and your replication setup efficiently replicates the disaster
(sometimes this is a query that should have had a WHERE clause but
didn't) on all of your slaves. For that reason, keeping binary
logs since your last backup is a good idea even if replication never
gets that far behind.

It says in the mysql manual :
If you are using replication, you should not delete old binary log
files until you are sure that no slave still needs to use them. For
example, if your slaves never run more than three days behind, once a
day you can execute mysqladmin flush-logs on the master and then
remove any logs that are more than three days old. You can remove the
files manually, but it is preferable to use PURGE MASTER LOGS, which
also safely updates the binary log index file for you (and which can
take a date argument as of MySQL 4.1). See Section 13.6.1.1, "PURGE
MASTER LOGS Syntax".
http://dev.mysql.com/doc/refman/4.1/en/binary-log.html

This seems to suggest that you need to estimate an amount of time it
will take for all slaves to be up to date, or have processed all the
binary log files. If this is the case, how do you take into account
something going wrong with the slave/s by not deleting the binary logs
if this happens?

It seems like a better idea to just remove the binary logs when the
master has full evidence that all the slaves have correctly processed
them (I/O thread retrieved them)... is there a way to do this?

The master doesn't have that kind of evidence.

Ok, that all makes sense, what I wanted to remove them before the /var/
lib/mysql directory filled up and choked mysql. I guess this is the
sort of thing should be part of a backup procedure.

Thanks