NOTE: On a MySQL replication environment, users must be careful in deleting binary logs. If slaves are lagging behind the server SOME days, the binary log purge might cause replication to fail. Make sure the logs file are not in use before removing them!

In any case here are some useful examples for purging binary log files easiliy. We’ll show you two quick ways on deleting the expired bin-log files.

As the purge work here is issued by mysql itself, please make sure you have MySQL-4.1 and later version installed. For version 4.0 and 3.xx, it does not support the following feathers.

1, Delete MySQL bin-log files by PURGE statement

For example, if you need to delete all binary logs older than 7 days, you just need to run this sql:

mysql> PURGE BINARY LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 7 DAY);

To purge all logs before a specific date:

mysql> PURGE MASTER LOGS BEFORE '2010-03-01 00:00:00';

To purge logs automatically (every Monday at 3am) you could use a cron job like this:

0 3 * * mon mysql -uroot -e 'PURGE BINARY LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 7 DAY)'

2, Remove bin-log by the variable expire_log_days

An alternative option is to set “expire_log_days” as MySQL server parameter. The default values for expire_log_days is not to purge logs. You can either set it in MySQL’s configuration file or in a command terminal like below:

mysql> SET GLOBAL expire_logs_days = 7;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like 'expire_%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| expire_logs_days |  7    |
+------------------+-------+
1 row in set (0.00 sec)

When this vavirable takes effect, the log files will be removed automatically on a weekly basis.
For any issues, don’t forget to raise a thread at our database support forum here.

Basically what you need to do is to retrival a snapshot of your master database. It covers three types of information, a snapshot of your current mysql database, and master log file name and its running position when this snapshot created.

You can achieve these information on a running DB like this:

Firstly, frozen your database, in order to disable any writes/updates on the databases. It affects your service for sure. Run two sql queries on a terminal:

mysql> FLUSH TABLES WITH READ LOCK;
Query OK, 0 rows affected (0.53 sec)

mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| binlog-db.000004 |  88689   |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.01 sec)

Keep this session open.  Note that when this session closes, READ LOCK will vanish, and your database will keep changing again.

Then open another terminal to create a copy of your current database files. There are three common ways to do that depending on your system environment. Either of these methods is okay.

1, Use mysqldump to copy all the data.

The disadvantage for mysqldump is that it uses very long time for dumpping large databases. It’s really unacceptable on productive servers.

shell$ mysqldump --database db1 db2 > fullbackup-timestamp.sql

2, Use a LVM snapshot

It only takes some seconds to create a LVM snapshot. When your snapshot created, you can copy the snapshot to the slave server.
As all the database files are exactly the same as master DB, you need to make sure the configuration files are similar as well.

3, Use XFS’ frozen feature to do that

SYSTEM xfs_freeze -f /var/lib/mysql;
SYSTEM YOUR_SCRIPT_TO_CREATE_SNAPSHOT.sh;
SYSTEM xfs_freeze -u /var/lib/mysql;

After the snapshot createed, you either leave the first session, or submit this query directly:

mysql> UNLOCK TABLES;

Finally you need to restore these databases from mysql dump file or the snapshot at slave side. When recovering a large database, time make lots of sense. it might take you one or more days to finish a recovery.
To speed up a mysql recovery, there’re always some valuable advises from wise man (The wise man here is … my friend). for example you can disable binlog when importing large sql files.

mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0.00 sec)

mysql> SOURCE /PATH/TO/MYSQL-BACKUP.SQL

When the files are importing, you need to make sure there are enough disk space avaiable, otherwise, it would crashed again. After importing all data files at slave side,  you need to tell the slave at which point it should read binlog from master:

mysql> SLAVE STOP;

mysql> SLAVE RESET;

mysql> CHANGE MASTER TO MASTER_HOST='pub.admon.org',MASTER_LOG_FILE='binlog-db.000004',MASTER_LOG_POS=88689;

myql> SLAVE START;

If all your recovery work is a remote operation, using Screen is highly suggested.

1 – Identifying The Problem

To find out whether replication is working or not, and check mysql logs
to make sure what caused it to stop. On Debian, MySQL logs to
/var/log/syslog:

admon:/home/admin# grep mysql /var/log/syslog
server1:/home/admin# grep mysql /var/log/syslog
Jun 29 09:16:08 http2 mysqld[14380]: 080629 9:16:08 [ERROR] Slave: Error
'Table 'mydb.taggregate_temp_1212347876' doesn't exist' on query. Default database: 'mydb'. Query: 'UPDATE thread AS thread,taggregate_temp_1212347876 AS aggregate
Jun 29 09:16:08 http2 mysqld[14380]: ^ISET thread.views = thread.views + aggregate.views
Jun 29 09:16:08 http2 mysqld[14380]: ^IWHERE thread.threadid = aggregate.threadid', Error_code: 1146
Jun 29 09:16:08 http2 mysqld[14380]: 080629 9:56:08 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.001079' position 203015142

Now, you can see the query that caused the error, and the stop position. To determine the exact query:

mysql> SHOW SLAVE STATUSG
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
....
Last_Errno: 1146
Last_Error: Error 'Table 'mydb.taggregate_temp_1212347876' doesn't exist' on query. Default database: 'mydb'.
Query: 'UPDATE thread AS thread,taggregate_temp_1212347876 AS aggregate
SET thread.views = thread.views + aggregate.views
WHERE thread.threadid = aggregate.threadid'
Skip_Counter: 0
......
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
1 row in set (0.00 sec)
mysql>

New we are prepare to fix this issue.
2 – Repairing The Replication
we need to stop the slave first, by running:

mysql> STOP SLAVE;

To Fix the issue is quite easy. We tell the slave to simply skip the invalid SQL query here:

mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;

This tells the slave to skip one query (which is the invalid one that
caused the replication to stop). If you wanna skip two queries, you’d
use SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 2; instead and so on.

Now the issue has been fixed, we can start the slave again by running:

mysql> START SLAVE;

and then,check if replication is working smoothly again.