Replication - binary log auto removal after processing
3 Message(s) by 2 Author(s) originally posted in mysql database
| From: tech101 |
Date: Thursday, April 12, 2007
|
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 shouldn't
delete old binary log
file s 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!
| From: gordonb.bmgki |
Date: Thursday, April 12, 2007
|
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
include s the one
you have not finished building yet, and does not include the one that
caught fire last week and has not 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 does not
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've had a WHERE
clause but
did not) 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 shouldn't 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 does not have that kind of evidence.
| From: tech101 |
Date: Thursday, April 12, 2007
|
wrote in message:
>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 have not finished building yet, and does not include the one that
caught fire last week and has not 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 does not
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've had a WHERE clause but
did not) 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 shouldn't 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 does not 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
Next Message: Trouble installing the MySQL GUI Tools with Red Hat 8.0