8.4 中文镜像

MySQL 8.4 参考手册 · 中文镜像

正文为中文,英文原文默认隐藏。点击任意中文段落即可展开 / 收起对应英文原文。

打开官方英文原文 ↗

译文由机器翻译生成,仅供理解参考;有疑问请以官方英文原文为准。

中文点击中文段落可显示 / 隐藏英文原文本页译文覆盖 100%

9.3.2 使用备份进行恢复9.3.2 Using Backups for Recovery

现在,假设我们在星期三上午 8 点发生了一次灾难性的意外退出,需要从备份中恢复。要进行恢复,首先我们恢复我们拥有的最后一次完整备份(即星期天下午 1 点的那次)。完整备份文件只是一些 SQL 语句,因此恢复起来非常容易:Now, suppose that we have a catastrophic unexpected exit on Wednesday at 8 a.m. that requires recovery from backups. To recover, first we restore the last full backup we have (the one from Sunday 1 p.m.). The full backup file is just a set of SQL statements, so restoring it is very easy:

$> mysql < backup_sunday_1_PM.sql

此时,数据已恢复到星期天下午 1 点的状态。要恢复自那时以来所做的更改,我们必须使用增量备份;也就是 gbichot2-bin.000007 和 gbichot2-bin.000008 二进制日志文件。如有必要,请从备份位置获取这些文件,然后按如下方式处理其内容:At this point, the data is restored to its state as of Sunday 1 p.m.. To restore the changes made since then, we must use the incremental backups; that is, the gbichot2-bin.000007 and gbichot2-bin.000008 binary log files. Fetch the files if necessary from where they were backed up, and then process their contents like this:

$> mysqlbinlog gbichot2-bin.000007 gbichot2-bin.000008 | mysql

我们现在已经将数据恢复到周二下午 1 点的状态,但仍然缺失从该日期到崩溃日期之间的更改。为了不丢失这些更改,我们需要让 MySQL 服务器将其 MySQL 二进制日志存储到安全位置(RAID 磁盘、SAN 等),而非存放数据文件的位置,以确保这些日志不在被破坏的磁盘上。(也就是说,我们可以使用 --log-bin 选项启动服务器,并指定一个与数据目录所在物理设备不同的位置。这样,即使包含数据目录的设备丢失,日志也会安全。)如果我们这样做了,我们会有 gbichot2-bin.000009 文件(以及任何后续文件),并且可以使用 mysqlbinlog 和 mysql 来应用这些日志,以在崩溃时刻之前恢复最近的数据更改而不丢失:We now have recovered the data to its state as of Tuesday 1 p.m., but still are missing the changes from that date to the date of the crash. To not lose them, we would have needed to have the MySQL server store its MySQL binary logs into a safe location (RAID disks, SAN, ...) different from the place where it stores its data files, so that these logs were not on the destroyed disk. (That is, we can start the server with a --log-bin option that specifies a location on a different physical device from the one on which the data directory resides. That way, the logs are safe even if the device containing the directory is lost.) If we had done this, we would have the gbichot2-bin.000009 file (and any subsequent files) at hand, and we could apply them using mysqlbinlog and mysql to restore the most recent data changes with no loss up to the moment of the crash:

$> mysqlbinlog gbichot2-bin.000009 ... | mysql

有关使用 mysqlbinlog 处理二进制日志文件的更多信息,请参见 第 9.5 节,“时间点(增量)恢复”。For more information about using mysqlbinlog to process binary log files, see Section 9.5, “Point-in-Time (Incremental) Recovery”.