MySQL 备份和恢复
如果发生意外情况，您的业务可能会受到影响。硬件故障、数据库损坏、用户错误，甚至是恶意攻击都可能会造成数据丢失风险。即使发生问题，数据库备份也能帮助您恢复业务并使其正常运行。如果一切正常，数据库备份可让您将数据库恢复到过去的特定时间点，从而帮助您满足合规性和审核要求。
MySQL 支持多种数据库备份选项，每种方案都具有不同的强度。您可以根据自己的需求选择任意组合方法。
备份类型
备份 MySQL 数据库有两种主要方式：物理方式和逻辑方式。物理备份会复制实际数据文件，而逻辑备份会生成 CREATE TABLE 和 INSERT 等可重新创建数据的语句。
物理备份
物理备份包含磁盘上存在的所有文件和目录的原始副本。这种类型的备份适用于大型数据库，因为与进行逻辑备份相比，复制原始文件要快得多。
优点：
- 物理备份简单而高效；它们不需要太多内存或大量 CPU 周期即可运行
- 物理备份无需执行任何额外操作即可生成原始文件；只需将原始文件和目录复制到备份位置即可
- 与逻辑备份相比，物理备份的恢复速度更快，因为 MySQL 不需要重新创建数据库对象并导入数据
缺点：
- 物理备份通常比逻辑备份占用更多的空间，因为除了 InnoDB 表空间（它们是共享的并且基于 table.ibd 文件，通常有碎片空间）之外，它们还包含事务日志、撤消日志和其他内容
- 物理备份并不总是能够在平台、操作系统和 MySQL 版本之间移植
- 由于物理备份会复制原始文件，因此如果这些文件出现任何底层损坏，也会复制到原始备份文件中。
MySQL 生态系统中的一些常见物理备份工具
逻辑备份
逻辑备份以 MySQL 可以解释为 SQL 或分隔文本的形式包含数据库中的数据。它是数据库的表示法，采用一系列 SQL 语句的形式，可以执行以重新创建数据库对象并导入数据。此类备份适用于小型数据库，因为逻辑备份的恢复时间可能比恢复物理备份长得多。当迁移到云中的代管式数据库服务或从中迁移时，此备份类型也很有用。
优点：
- 逻辑备份非常灵活。它们在服务器级别（所有数据库）、数据库级别（特定数据库中的所有表）、表级别甚至行级别（匹配给定 WHERE 条件的表行）的备份和恢复操作上提供高粒度。
- 逻辑备份更易于恢复，只需将备份文件传输至 mysql 客户端，并使用 LOAD DATA 语句或 mysqlimport 命令加载以文本分隔的文件。
- 逻辑备份可以从另一台机器远程运行，让您可以在网络上备份和恢复数据库。这对于 Google Cloud SQL、Amazon RDS 和 Microsoft Azure 等云数据库非常有用，其中用户无法直接访问虚拟机。
- 逻辑备份有助于避免数据损坏。物理备份可能会损坏，在验证之前可能不会被注意到。由于逻辑备份通常是文本文件，因此使用文本编辑器查看这些备份更容易，也更容易发现任何损坏情况。逻辑备份很少损坏。
- 与物理备份不同，逻辑备份在平台、操作系统和 MySQL 版本之间具有高度可移植性。
- 逻辑备份具有高度压缩性。
缺点：
- 逻辑备份的创建速度较慢，因为您需要查询 MySQL 服务器以获取架构和行，然后转换为逻辑格式
- 逻辑备份的恢复速度也较慢，因为 MySQL 需要执行 SQL 语句才能创建表、导入行以及重新构建索引
- 与物理备份相比，逻辑备份需要更多服务器资源（CPU、RAM 和磁盘 I/O）来执行备份和恢复操作
一些常见的逻辑备份工具
MySQL Shell 实用程序 - dump | load
时间点恢复 (PITR)
顾名思义，时间点恢复可帮助您将实例恢复到特定时间点。例如，如果错误导致数据丢失，您可以将数据库恢复到错误发生前的状态。
PITR 是一个两步式流程，它依赖于二进制日志：
- 恢复完整的物理或逻辑备份，使服务器处于备份时的状态
- 应用二进制日志以重放备份时间与所需时间点之间的更改
二进制日志包含对数据库实例所做的任何更改，例如创建表、插入/更新/删除行等。例如，假设您的每日备份时间是上午 6:00，并且您希望能够在上午 10:15 之前随时恢复实例。若要在上午 10:15 恢复状态，您需要先从早上 6:00 恢复完整备份，然后再从早上 6:00 重放二进制日志事件，直到上午 10:15。这会让服务器在期望的时间达到所需状态。
必须提供二进制日志以进行复制和 PITR；它们与底层数据同等重要。需要实时备份二进制日志才能使它们在恢复规划中有效，您可以使用 mysqlbinlog 命令下载这些日志。
例如：
|
mysqlbinlog --host=<hostname> --port=<port> --user=<user> --password=<password> --read-from-remote-server --raw --stop-never <binlog_filename> |
<binlog_filename> 将会是第一个下载的文件，之后 mysqlbinlog 将自动切换到下一个文件。这些二进制日志会写入运行 mysqlbinlog 命令的服务器的当前目录中。您可以使用 --result-file 选项更改文件名和位置。您还可以使用 --stop-never 选项，使 mysqlbinlog binlog 保持与服务器的连接，并在写入时下载新的更改。
您可以在 mysqlbinlog 手册中详细了解如何连接到远程服务器，并在写入二进制日志时下载二进制日志。
在 Cloud SQL for MySQL 中备份和恢复
作为 Google Cloud 的 MySQL 代管式数据库服务，Cloud SQL 提供自动备份和时间点恢复 (PITR) 来保护数据。这些设置默认处于启用状态，是在 Cloud SQL for MySQL 实例上启用高可用性 (HA) 所必需的。
任何 Cloud SQL 备份都是一种物理备份，因为它们是在永久性磁盘 (PD) 上截取的快照。 Cloud SQL 提供了自动执行备份的灵活性，您也可以随时按需执行备份。您仍然可以使用标准 MySQL 逻辑备份工具（如 mysqldump、mydumper、mysqlpump 等）进行逻辑备份，而不会干扰您的代管式备份。
我们来深入了解一下 Cloud SQL 备份的工作原理。
了解 Cloud SQL 快照
Cloud SQL 使用永久性磁盘 (PD) 进行存储，并且每个 Cloud SQL 实例都有一个永久性的数据存储磁盘，用于存储数据库文件和目录。
Cloud SQL 使用 PD 快照进行备份，这些快照会引用数据磁盘在给定时间点的状态。PD 的第一个快照是一个完整的快照，其中包含 PD 上的所有数据，后续的快照则是增量快照，只包含自上一个快照创建以来的任何新数据或修改的数据。 您可以将这些快照视为永久性数据磁盘的云代管式物理副本，它们是 Cloud SQL 所有备份和恢复功能（包括 PITR）的基础。
Cloud SQL 备份
Cloud SQL 执行两种类型的代管式备份：自动备份和按需备份。默认情况下，这两种类型都存储在距离实例最近的多区域位置。例如，如果您的 Cloud SQL 实例位于 us-central1，则备份默认存储在美国多区域。 但是，诸如 australia-southeast1 等默认位置位于多区域之外，并将放置在最近的多区域（即亚洲）中。您还可以为备份选择一个自定义位置。
自动备份
自动备份会按您选择的 4 小时时间段每天进行一次。备份会在备份时段内开始，并可在备份完成之前继续进行，直到备份完成为止。您可以配置要保留的自动备份数量（从 1 个到 365 个）。默认保留政策是保留最近七个备份。
按需备份
您还可以随时创建按需备份。如果您需要进行备份，但不想等待备份期，则可以使用这些选项。此外，与自动备份不同，按需备份不会自动删除。此类备份会一直留存到您删除它们或其实例被删除为止。
恢复 Cloud SQL 备份
您可以将备份恢复到截取它的同一实例或同一项目中的其他实例。请注意，目标实例本身不应是读取副本，也不应在恢复备份时具有读取副本，因为读取副本是主实例的副本并存在副本丢失的风险。之后，您可以随时添加读取副本。
恢复备份时会基于该备份快照创建新的永久性磁盘，并将其挂接到实例。该数据库将开始使用新磁盘并执行标准 MySQL 崩溃恢复过程，然后再恢复为刚刚从快照恢复的成熟 MySQL 数据库。
恢复到同一实例
当您将备份恢复到相同实例时，即是让该实例上的数据返回到进行备份时的状态。
恢复到不同实例
当您使用备份恢复到不同实例时，即是让目标实例上的数据更新为进行备份时源实例的状态。
重要提示：恢复备份会覆盖目标实例上的所有当前数据，包括之前的时间点恢复日志。被覆盖的数据无法恢复。
Cloud SQL 时间点恢复 (PITR)
在 Cloud SQL 中，PITR 始终会创建一个新实例，该实例会继承源实例的设置，类似于克隆实例操作。此功能需要在源实例上同时启用自动备份和时间点恢复（二进制日志）。二进制日志的默认保留政策为 7 天，您可以将保留期限配置为 1 至 7 天。
实现 PITR 的方法是，通过原始实例的备份创建一个新实例，并将存储在原始实例数据磁盘上的二进制日志重放到给定点。
在 Cloud SQL 中执行 PITR 时，客户可以选择克隆实例的当前状态，也可以克隆到过去的时间戳。
用于执行 PITR 的界面如下所示。
相关产品和服务
Google Cloud 提供旨在满足您业务需求的代管式 MySQL 数据库，可以完成包括弃用本地数据中心、运行 SaaS 应用和迁移核心业务系统在内的各种任务。
