MySQL 备份和恢复

备份 MySQL 数据库有两种主要方式：物理方式和逻辑方式。物理备份会复制实际数据文件，而逻辑备份会生成可重新创建数据的语句（如 CREATE TABLE 和 INSERT）。

物理备份包含磁盘上存在的所有文件和目录的原始副本。这种类型的备份适用于大型数据库，因为与进行逻辑备份相比，复制原始文件要快得多。

优点：

• 物理备份简单而高效；它们无需太多内存或许多 CPU 周期即可运行

• 物理备份无需任何额外操作即可生成原始文件；您只需将原始文件和目录复制到备份位置

• 物理备份的恢复速度比逻辑备份更快，因为 MySQL 不必重新创建数据库对象并导入数据

缺点：

• 物理备份通常比逻辑备份占用更多的空间，因为除了 InnoDB 表空间（它们是共享的并且基于 table.ibd 文件，通常有碎片空间）之外，它们还包含事务日志、撤消日志和其他内容

• 物理备份并非总能跨平台、操作系统和 MySQL 版本移植

• 由于物理备份会复制原始文件，因此如果这些文件存在任何底层损坏，则这些文件也会复制到备份文件

MySQL 生态系统中一些常见的物理备份工具

• MySQL Enterprise Backup 
• Percona XtraBackup
• MariaDB Mariabackup

逻辑备份以 MySQL 可以解释为 SQL 或分隔文本的形式包含数据库中的数据。它是数据库的表示形式，可执行 SQL 语句序列来重新创建数据库对象和导入数据。此类备份适用于小型数据库，因为与恢复物理备份相比，逻辑备份的恢复时间要长得多。当迁移到云中的托管式数据库服务或从中迁移时，此备份类型也很有用。

优点：

• 逻辑备份非常灵活。它们在服务器级别（所有数据库）、数据库级别（特定数据库中的所有表）、表级别甚至行级别（匹配给定 WHERE 条件的表行）的备份和恢复操作上提供高粒度。

• 逻辑备份更易于恢复，只需将备份文件传送到 mysql 客户端，并使用 LOAD DATA 语句或 mysqlimport 命令来加载以文本分隔的文件即可。

• 逻辑备份可以从其他机器远程运行，使您能够通过网络备份和恢复数据库。这对于用户无法直接访问虚拟机的云数据库（例如 Google Cloud SQL、Amazon RDS 和 Microsoft Azure）非常有用。

• 逻辑备份有助于避免数据损坏。物理备份可能会损坏，在验证之前可能不会被注意到。由于逻辑备份通常是文本文件，因此使用文本编辑器查看这些备份更容易，也更容易发现任何损坏情况。逻辑备份很少损坏。

• 与物理备份不同，逻辑备份跨平台、操作系统和 MySQL 版本具有高度可移植性。

• 逻辑备份的可压缩性极强。

缺点：

• 创建逻辑备份的速度较慢，因为您需要查询 MySQL 服务器来获取架构和行，然后将其转换为逻辑格式

• 逻辑备份的恢复速度也较慢，因为 MySQL 需要执行 SQL 语句来创建表、导入行和重建索引

• 与物理备份相比，逻辑备份需要更多服务器资源（CPU、RAM 和磁盘 I/O）来执行备份和恢复操作

一些常见逻辑备份工具

• mysqldump
• mydumper
• mysqlpump

MySQL Shell 实用程序 - dump | load

顾名思义，时间点恢复可帮助您将实例恢复到特定的时间点。例如，如果错误导致数据丢失，您可以将数据库恢复到错误发生前的状态。

PITR 分为两个步骤，依赖于二进制日志：

1. 恢复完整的物理备份或逻辑备份，使服务器处于备份时的状态
2. 应用二进制日志，以重放从备份时间到所需时间点之间的更改

二进制日志包含对数据库实例所做的任何更改，例如创建表、行插入/更新/删除等。例如，假设您的每日备份时间是上午 6:00，并且您希望能够在上午 10:15 之前随时恢复实例。若要在上午 10:15 恢复状态，您需要先从早上 6:00 恢复完整备份，然后再从早上 6:00 重放二进制日志事件，直到上午 10:15。这会让服务器在期望的时间达到所需状态。

二进制日志对于复制和 PITR 是必需的；它们与底层数据一样重要。二进制日志需要实时备份，这样才能有效地制定恢复计划。您可以使用 mysqlbinlog 命令下载二进制日志。

例如：

<binlog_filename> 将会是第一个下载的文件，之后 mysqlbinlog 将自动切换到下一个文件。这些二进制日志会写入运行 mysqlbinlog 命令的服务器的当前目录中。您可以使用 --result-file 选项更改文件名和位置。您也可以使用 --stop-never 选项让 mysqlbinlog binlog 保持与服务器的连接，并在写入新更改时下载更改。

如需详细了解如何连接到远程服务器并在写入二进制日志时下载二进制日志，请参阅 mysqlbinlog 手册。

作为 Google Cloud 的 MySQL 托管式数据库服务，Cloud SQL 提供了自动备份和时间点恢复 (PITR) 功能来保护数据。默认情况下，这些功能处于启用状态，并且是在 Cloud SQL for MySQL 实例上启用高可用性 (HA) 所必需的功能。

任何 Cloud SQL 备份都是一种物理备份，因为它们是在永久性磁盘 (PD) 上截取的快照。Cloud SQL 提供了自动执行备份的灵活性，您也可以随时按需执行备份。您仍然可以使用标准 MySQL 逻辑备份工具（如 mysqldump、mydumper、mysqlpump 等）进行逻辑备份，而不会干扰您的托管式备份。

我们来深入了解一下 Cloud SQL 的备份的工作原理。

Cloud SQL 使用永久性磁盘 (PD) 存储数据，而每个 Cloud SQL 实例都挂接了一个永久性数据磁盘，用于存储数据库文件和目录。

Cloud SQL 使用 PD 快照进行备份，这些快照会引用数据磁盘在给定时间点的状态。永久性磁盘的第一个快照是包含该永久性磁盘上所有数据的完整快照，后续快照是增量快照，仅包含自上一个快照创建以来的任何新数据或修改的数据。您可以将这些快照视为永久性数据磁盘的云托管式物理副本，它们是 Cloud SQL 所有备份和恢复功能（包括 PITR）的基础。

Cloud SQL 可执行两种类型的托管式备份：自动备份和按需备份。默认情况下，这两种类型都存储在距离实例最近的多区域位置。例如，如果 Cloud SQL 实例位于 us-central1，则您的备份默认存储在美国多区域中。但是，像 australia-southeast1 这样的默认位置不在多区域范围之内，并将放置在最近的多区域（即亚洲）内。您还可以为备份选择自定义位置。

自动备份

系统每天在您选择的 4 小时内进行自动备份。备份会在备份时段内开始，并可能会在备份时段之外继续运行，直到完成为止。您可以配置要保留的自动备份数量（从 1 个到 365 个）。默认保留政策是保留七个最近的备份。

按需备份

您还可以随时创建按需备份。如果您需要备份并且不想等到备份时段，则这些按需备份将非常有用。此外，与自动备份不同，按需备份不会自动删除。此类备份会一直留存到您删除它们或其实例被删除为止。

您可以将备份恢复到创建备份的同一实例，也可以恢复到同一项目中的不同实例。请注意，目标实例本身不应是读取副本，也不应在恢复备份时具有读取副本，因为读取副本是主实例的副本并存在副本丢失的风险。您之后可以随时添加读取副本。

如果恢复备份，系统会基于该备份快照创建一个新的永久性磁盘并将其挂接到实例。数据库开始使用新磁盘并执行标准的 MySQL 崩溃恢复过程，然后作为刚从快照中恢复的完整 MySQL 数据库联机。

恢复到同一实例

当您将备份恢复到相同实例时，即是让该实例上的数据返回到进行备份时的状态。

恢复到不同实例

当您使用备份恢复到不同实例时，会将目标实例上的数据更新为之前创建备份时源实例所处的状态。

重要提示：恢复备份会覆盖目标实例上的所有当前数据，包括之前的时间点恢复日志。被覆盖的数据无法恢复。

在 Cloud SQL 中，PITR 会始终创建一个继承源实例的设置的新实例，这与克隆实例操作类似。此功能要求在源实例上启用自动备份和时间点恢复（二进制日志）。二进制日志的默认保留政策为 7 天，您可以将保留期限配置为 1 到 7 天之间的任何值。

PITR 可通过以下方法实现：基于原始实例的备份创建新实例，并将存储在原始实例数据磁盘上的二进制日志重放至指定点。

在 Cloud SQL 中执行 PITR 时，客户可以选择克隆实例的当前状态，或克隆到过去的时间戳。

用于执行 PITR 的界面如下所示。