content_image/744786.jpg
-rw-rw---- 1 guilhem guilhem 79 Nov 11 11:06 gbichot2-bin.000003 -rw-rw---- 1 guilhem guilhem 508 Nov 11 11:08 gbichot2-bin.000004 -rw-rw---- 1 guilhem guilhem 220047446 Nov 12 16:47 gbichot2-bin.000005 -rw-rw---- 1 guilhem guilhem 998412 Nov 14 10:08 gbichot2-bin.000006 -rw-rw---- 1 guilhem guilhem 361 Nov 14 10:07 gbichot2-bin.index 

Each time it restarts, the MySQL server creates a new binary log file using the next number in the sequence. While the server is running, you can also tell it to close the current binary log file and begin a new one manually by issuing a FLUSH LOGS  SQL statement or with a mysqladmin flush-logs command. mysqldump  also has an option to flush the logs. The .index  file in the data directory contains the list of all MySQL binary logs in the directory. 

The MySQL binary logs are important for recovery because they form the set of incremental backups. If you make sure to flush the logs when you make your full backup, the binary log files created afterward contain all the data changes made since the backup. Let’s modify the previous mysqldump  command a bit so that it flushes the MySQL binary logs at the moment of the full backup, and so that the dump file contains the name of the new current binary log: 

shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases > backup_sunday_1_PM.sql 

After executing this command, the data directory contains a new binary log file, gbichot2-bin.000007 , because the --flush-logs  option causes the server to flush its logs. The --master-data  option causes mysqldump  to write binary log information to its output, so the resulting .sql  dump file includes these lines: 

-- Position to start replication or point-in-time recovery from -- CHANGE MASTER TO MASTER_LOG_FILE=’gbichot2-bin.000007’,MASTER_LOG_POS=4; 

Because the mysqldump  command made a full backup, those lines mean two things: 

•The dump file contains all changes made before any changes written to the gbichot2-bin.000007 binary log file or higher. 

•All data changes logged after the backup are not present in the dump file, but are present in the gbichot2-bin.000007  binary log file or higher. 

On Monday at 1 p.m., we can create an incremental backup by flushing the logs to begin a new binary log file. For example, executing a mysqladmin flush-logs  command creates gbichot2-bin.000008 . All changes between the Sunday 1 p.m. full backup and Monday 1 p.m. are written in gbichot2- bin.000007 . This incremental backup is important, so it is a good idea to copy it to a safe place. (For example, back it up on tape or DVD, or copy it to another machine.) On Tuesday at 1 p.m., execute another mysqladmin flush-logs  command. All changes between Monday 1 p.m. and Tuesday 1 p.m. are written in gbichot2-bin.000008  (which also should be copied somewhere safe). 

The MySQL binary logs take up disk space. To free up space, purge them from time to time. One way to do this is by deleting the binary logs that are no longer needed, such as when we make a full backup: 

shell> mysqldump --single-transaction --flush-logs --master-data=2 \ --all-databases --delete-master-logs > backup_sunday_1_PM.sql 

<img src='content_image/744786.jpg'>

## Note 

Deleting the MySQL binary logs with mysqldump --delete-master-logs  can be dangerous if your server is a replication source server, because replicas might not yet fully have processed the contents of the binary log. The description for the PURGE BINARY LOGS  statement explains what should be verified before deleting the MySQL binary logs. See Section 13.4.1.1, “PURGE BINARY LOGS Statement” . 

