如果发生意外情况,您的业务可能会受到影响。硬件故障、数据库损坏、用户错误,甚至是恶意攻击都可能会造成数据丢失的风险。即使出现问题,数据库备份也能帮助您恢复业务并保持业务正常运转。当一切进展顺利时,数据库备份可让您将数据库恢复到过去的特定时间点,从而帮助您满足合规性和审核要求。
MySQL 支持多种数据库备份选项,每种选项都有各自的优势。您可以选择最适合自己需求的方法组合。
备份 MySQL 数据库有两种主要方式:物理方式和逻辑方式。物理备份会复制实际数据文件,而逻辑备份会生成可重新创建数据的语句(如 CREATE TABLE 和 INSERT)。
物理备份包含磁盘上存在的所有文件和目录的原始副本。这种类型的备份适用于大型数据库,因为与进行逻辑备份相比,复制原始文件要快得多。
优点:
缺点:
MySQL 生态系统中一些常见的物理备份工具
逻辑备份以 MySQL 可以解释为 SQL 或分隔文本的形式包含数据库中的数据。它是数据库的表示形式,可执行 SQL 语句序列来重新创建数据库对象和导入数据。此类备份适用于小型数据库,因为与恢复物理备份相比,逻辑备份的恢复时间要长得多。当迁移到云中的托管式数据库服务或从中迁移时,此备份类型也很有用。
优点:
缺点:
一些常见逻辑备份工具
MySQL Shell 实用程序 - dump | load
顾名思义,时间点恢复可帮助您将实例恢复到特定的时间点。例如,如果错误导致数据丢失,您可以将数据库恢复到错误发生前的状态。
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 手册。
作为 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 的界面如下所示。