Mysql官方文档翻译系列-7.3.1 Establishing a Backup Policy

原文链接

(https://dev.mysql.com/doc/refman/5.7/en/backup-policy.html)

正文

To be useful, backups must be scheduled regularly. A full backup (a snapshot of the data at a point in time) can be done in MySQL with several tools. For example, MySQL Enterprise Backup can perform a physical backup of an entire instance, with optimizations to minimize overhead and avoid disruption when backing up InnoDB data files; mysqldump provides online logical backup. This discussion uses mysqldump.

要想数据库发挥用处，备份必须有规律地列入计划之中。在mysql中，一个完整备份（某一时间点的数据库快照）能够用几个小工具完成。

比如，Mysql企业版的Backup能够进行一个完整实例的物理备份，该功能能避免备份Innodb数据文件过程中对业务的中断；mysqldump能提供运行时逻辑备份。本节主要讨论mysqldump。

Assume that we make a full backup of all our InnoDB tables in all databases using the following command on Sunday at 1 p.m., when load is low:

shell> mysqldump --all-databases --master-data --single-transaction > backup_sunday_1_PM.sql

The resulting .sql file produced by mysqldump contains a set of SQL INSERT statements that can be used to reload the dumped tables at a later time.

假设我们正在星期六下午1点使用如下命令来进行全数据库中所有Innodb表的全量备份，此时负载较低：

shell> mysqldump --all-databases --master-data --single-transaction > backup_sunday_1_PM.sql

mysqldump产生的.sql文件包含了一系列的SQL INSERT语句，这些语句能够用来在以后重新载入转储表中的数据。

This backup operation acquires a global read lock on all tables at the beginning of the dump (using FLUSH TABLES WITH READ LOCK). As soon as this lock has been acquired, the binary log coordinates are read and the lock is released. If long updating statements are running when the FLUSH statement is issued, the backup operation may stall until those statements finish. After that, the dump becomes lock-free and does not disturb reads and writes on the tables.

这个备份操作在dump开始时，需要获取在所有表上的全局读锁(用FLUSH TABLES WITH READ LOCK)。只要获取到该锁，二进制日志坐标被读取，然后锁被释放。

如果当flush语句正在运行时，有运行时间长的更新语句正在运行，备份操作可能推迟，直到那些语句完成。在那之后，dump操作不再需要锁，而且不影响对表的读写。

It was assumed earlier that the tables to back up are InnoDB tables, so --single-transaction uses a consistent read and guarantees that data seen by mysqldump does not change. (Changes made by other clients to InnoDB tables are not seen by the mysqldump process.) If the backup operation includes nontransactional tables, consistency requires that they do not change during the backup. For example, for the MyISAM tables in the mysql database, there must be no administrative changes to MySQL accounts during the backup.

假设dump的表都是Innodb引擎，因此--single-transaction使用一致性读，保证mysqldump看到的数据不会改变。（其他客户端对Innodb的修改对mysqldump是不可见的）

如果备份操作包含不支持事务的表，一致性要求他们在备份期间不被改变。比如，针对MyIsam引擎的表，备份期间一定不能修改mysql账户。

Full backups are necessary, but it is not always convenient to create them. They produce large backup files and take time to generate. They are not optimal in the sense that each successive full backup includes all data, even that part that has not changed since the previous full backup. It is more efficient to make an initial full backup, and then to make incremental backups. The incremental backups are smaller and take less time to produce. The tradeoff is that, at recovery time, you cannot restore your data just by reloading the full backup. You must also process the incremental backups to recover the incremental changes.

全量备份是必须的，但是并不总是方便去创建他们。他们产生较大的备份文件，且比较耗时。每个后续的全量备份都包含所有数据，即使自从上次备份后部分数据并未改变的情况下，这也许不是最优的。

最好是初始时进行全量备份，而后续只进行增量备份。增量备份产生的文件更小，且耗时也短。代价就是需要恢复时，你不能恢复全部的数据仅仅依靠加载全量备份。你必须处理增量部分的数据去恢复增量的改变。

To make incremental backups, we need to save the incremental changes. In MySQL, these changes are represented in the binary log, so the MySQL server should always be started with the --log-bin option to enable that log. With binary logging enabled, the server writes each data change into a file while it updates data. Looking at the data directory of a MySQL server that was started with the --log-bin option and that has been running for some days, we find these MySQL binary log files:

进行增量备份时，我们需要保存增量的改变。在mysql中，这些改变存放在二进制日志，因此mysql服务器总能使用--log-bin选项去开启二进制日志功能。二进制日志开启时，服务器将每一次的数据变更写入文件。

查看以--log-bin选项开启启动且运行了一些时日的mysql服务器实例的数据目录，我们发现这些二进制日志文件：

-rw-rw---- 1 guilhem  guilhem   1277324 Nov 10 23:59 gbichot2-bin.000001
-rw-rw---- 1 guilhem  guilhem         4 Nov 10 23:59 gbichot2-bin.000002
-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.

每次重启时，mysql使用下一个序列号创建一个新的二进制日志文件。当服务器运行时，你也可以执行FLUSH LOGS这个sql语句或者运行mysqladmin flush-logs，来告诉它关闭当前的二进制日志文件并且开始用一个新的文件来记录。

mysqldump也有一个选项去刷新日志文件。.index文件包含了目录中的所有二进制日志文件。

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:

二进制日志文件在恢复中至关重要，因为他们是增量备份的基础。如果你记得刷新日志文件当你完成你的全量备份后，这之后创建的二进制日志文件包含了自从上次备份后所有的数据变更。

我们修改前面的mysqldump命令，来让它在全量备份后使用新的二进制日志文件。并且，转储文件包含了新的当前二进制文件的名字:

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:

执行该命令后，数据目录包含了一个新文件， gbichot2-bin.000007，因为--flush-logs选项告诉服务器需要创建一个新的文件。 --master-data选项告诉mysqldump写二进制日志信息到它的输出，因此生成的.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 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.

因为mysqldump生成全量备份，那些行表示：

* 转储文件包含在gbichot2-bin.000007之前的全部变化(也就是说不包含在这个新文件中的变化)

* 新的数据变动会在 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 mysqladmin flush-logs command creates gbichot2-bin.000008. All changes between the Sunday 1 p.m. full backup and Monday 1 p.m. will be in the gbichot2-bin.000007 file. 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. will be in the gbichot2-bin.000008 file (which also should be copied somewhere safe).

在星期一下午1点，我们创建一个增量备份通过让mysql创建一个新的二进制日志文件。比如，执行mysqladmin flush-logs命令创建gbichot2-bin.000008.在星期日下午1点全量备份和星期一下午1点之间的变化就在 gbichot2-bin.000007中。

这个增量备份是重要的，所以我们可以拷贝它到一个安全的地方（比如备份在dvd，或者拷到另一台机器）。在星期二下午1点，我们执行mysqladmin flush-logs命令，那么星期1下午1点到星期二下午1点间的所有数据变化就存在于gbichot2-bin.000008。

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

Deleting the MySQL binary logs with mysqldump --delete-master-logs 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 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 Syntax”.

理解

我的理解是：mysqldump产生一个当前时刻的数据库快照，加--flush-logs选项会让mysql新产生一个二进制日志文件（旧的那个就不再变化了，数据截止到此时），而新的这个会包含从此刻开始，所有的数据变化。

--master-data=2选项是让mysqldump写一些信息到这个新的二进制日志文件中。

--delete-master-logs比较危险，如果在主从复制的架构下的话。