Oracle 5.0 Reference Manual page 644

the [1467]
--log-bin
log files:
-rw-rw---- 1 guilhem
-rw-rw---- 1 guilhem
-rw-rw---- 1 guilhem
-rw-rw---- 1 guilhem
-rw-rw---- 1 guilhem
-rw-rw---- 1 guilhem
-rw-rw---- 1 guilhem
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
command.
mysqldump
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
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,
bin.000007, because the
[302] option causes
master-data
resulting dump file includes these lines:
.sql
-- 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
• The dump file contains all changes made before any changes written to the
binary log file or newer.
bin.000007
• All data changes logged after the backup are not present in the dump file, but are present in the
gbichot2-bin.000007
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
bin.000008. All changes between the Sunday 1 p.m. full backup and Monday 1 p.m. will be in the
gbichot2-bin.000007
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
p.m. and Tuesday 1 p.m. will be in the
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
Note
Deleting the MySQL binary logs with
can be dangerous if your server is a replication master server, because slave
servers might not yet fully have processed the contents of the binary log. The
Establishing a Backup Policy
option and that has been running for some days, we find these MySQL binary
guilhem 1277324 Nov 10 23:59 gbichot2-bin.000001
guilhem 4 Nov 10 23:59 gbichot2-bin.000002
guilhem 79 Nov 11 11:06 gbichot2-bin.000003
guilhem 508 Nov 11 11:08 gbichot2-bin.000004
guilhem 220047446 Nov 12 16:47 gbichot2-bin.000005
guilhem 998412 Nov 14 10:08 gbichot2-bin.000006
guilhem 361 Nov 14 10:07 gbichot2-bin.index
FLUSH LOGS
also has an option to flush the logs. The
[300]
--flush-logs
mysqldump
command made a full backup, those lines mean two things:
binary log file or newer.
mysqladmin flush-logs
file. This incremental backup is important, so it is a good idea to copy it to
mysqladmin flush-logs
gbichot2-bin.000008
624
SQL statement or with a
.index
option causes the server to flush its logs. The
to write binary log information to its output, so the
command creates
command. All changes between Monday 1
file (which also should be copied
mysqldump --delete-master-logs
mysqladmin flush-logs
file in the data directory
command
mysqldump
gbichot2-
gbichot2-
gbichot2-
--