通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

在 Azure Database for MySQL - 灵活服务器中进行备份和还原

  • 项目

适用于：Azure Database for MySQL 灵活服务器

Azure Database for MySQL 灵活服务器会自动创建服务器备份，并将这些备份安全地存储在区域内的本地冗余存储中。 备份可以用来将服务器还原到某个时间点。 备份和还原是任何业务连续性策略的基本组成部分，因为它们可以保护数据免遭意外损坏或删除。

备份概述

Azure Database for MySQL 灵活服务器支持两种类型的备份，以提高维护业务关键型数据备份时的灵活性。

自动备份

Azure Database for MySQL 灵活服务器获取数据文件的快照备份，并将它们存储在本地冗余存储中。 服务器还执行事务日志备份，并将它们存储到本地冗余存储中。 可以通过这些备份将服务器还原到所配置的备份保留期中的任意时间点。 默认的备份保留期为七天。 可以选择将数据库备份配置为 1 到 35 天。 所有备份都使用针对静态存储数据的 AES 256 位加密进行加密。

按需备份

除了服务执行的自动备份之外，使用 Azure Database for MySQL 灵活服务器还可以触发生产工作负载的按需备份，并根据服务器的备份保留策略进行存储。 可以将这些备份用作最快的还原点来执行时间点还原，以减少高达 90% 的还原时间。 默认的备份保留期为七天。 可以选择将数据库备份配置为 1 到 35 天。 可以从门户触发总共 50 个按需备份。 所有备份都使用针对静态存储数据的 AES 256 位加密进行加密。

无法导出这些备份文件。 这些备份只能用于 Azure Database for MySQL 灵活服务器中的还原操作。 还可以使用 MySQL 客户端中的 mysqldump 来复制数据库。

备份频率

灵活服务器上的备份是基于快照的。 第一次快照备份在创建服务器后立即进行计划。 每天进行一次快照备份。 事务日志备份每五分钟进行一次。 如果计划内备份失败，备份服务会每隔 20 分钟尝试一次备份，直到备份成功执行。 这些备份失败的原因可能在于服务器实例上存在繁重的事务生产负载。

注意

  • 如果服务器遇到高事务负载，导致更大且增长更快的 binlog 文件，则备份服务将每天执行多个备份，以确保可以使用这些备份进行可靠且更快的还原。
  • 对于 5.7 服务器，长时间运行的/大型事务可能会阻碍全局实例级锁定获取，而这是成功进行每日备份所必需的。 在这种情况下，每日备份可能会失败。 若要解决此问题，请终止长时间运行的事务或重启服务器。 为了确保运行更顺畅，建议使用 主要版本升级将 MySQL 5.7 服务器升级到版本 8.0。

备份冗余选项

Azure Database for MySQL 灵活服务器存储备份的多个副本，以保护数据免受各种计划内和计划外事件的影响，包括暂时性的硬件故障、网络中断或断电、大范围自然灾害等。 使用 Azure Database for MySQL 灵活服务器时，可以灵活地在“基本”层、“常规用途”层和“业务关键”层中选择本地冗余、区域冗余或异地冗余备份存储。 默认情况下，Azure Database for MySQL 灵活服务器备份存储为具有相同区域高可用性 (HA) 或无高可用性配置的服务器提供本地冗余，为具有区域冗余 HA 配置的服务器提供区域冗余。

备份冗余可确保即使遇到故障，数据库也能满足其可用性和持续性目标，Azure Database for MySQL 灵活服务器向用户提供三个扩展选项：

  • 本地冗余备份存储：将备份存储在本地冗余备份存储中时，会将多个备份副本都存储在同一数据中心内。 此选项可保护数据免受服务器机架和驱动器故障的影响。 还可在一年中提供至少 99.999999999%（11 个 9）的备份对象持续性。 默认情况下，针对具有相同区域高可用性 (HA) 或无高可用性配置的服务器，将备份存储设置为本地冗余。

  • 区域冗余备份存储：将备份存储在区域冗余备份存储中时，不仅会将多个副本存储在托管服务器的可用性区域中，还会将它们复制到同一区域中的其他可用性区域。 此选项可用于需要高可用性或将数据复制限制在一个国家/地区内以满足数据驻留要求的方案。 还可在一年中提供至少 99.9999999999%（12 个 9）的备份对象持续性。 可在创建服务器时选择“区域冗余高可用性”选项，以确保区域冗余备份存储。 创建后可禁用服务器的高可用性，但备份存储继续保持区域冗余。

  • 异地冗余备份存储：将备份存储在异地冗余备份存储中时，不仅会将多个副本存储在托管服务器的区域中，还会将它们复制到异地配对的区域。 这样可以在发生灾难时提供更好的保护，并且可以将服务器还原到其他区域。 还可在给定的一年中提供至少 99.99999999999999%（16 个 9）的备份对象持续性。可在创建服务器时启用“异地冗余”选项，以确保异地冗余备份存储。 此外，还可以在创建服务器后从本地冗余存储移到异地冗余存储。 托管在任何 Azure 配对区域中的服务器都支持异地冗余。

注意

可支持区域冗余的区域冗余高可用性当前仅显示为创建时操作。 目前，对于区域冗余高可用性服务器，只能在创建服务器时启用/禁用异地冗余。

从其他备份存储选项移动到异地冗余备份存储

可使用以下建议方法将现有备份存储移到异地冗余存储：

  • 从本地冗余移到异地冗余备份存储 - 若要将备份存储从本地冗余存储移到异地冗余存储，可以从 Azure 门户更改“计算 + 存储”服务器配置，为本地冗余源服务器启用异地冗余。 同样，也可以使用类似方式将相同区域冗余 HA 服务器还原为异地冗余服务器，如基础备份存储是本地冗余一样。

  • 从区域冗余移动到异地冗余备份存储 - Azure Database for MySQL 灵活服务器不支持通过在已预配服务器后更改“计算 + 存储”设置来实现区域冗余存储到异地冗余存储的转换。 若要将备份存储从区域冗余存储移动到异地冗余存储，存在两个选项：a) 使用 PITR（时间点还原）还原拥有所需配置的服务器。 b) 新建拥有所需配置的服务器，并使用转储和还原迁移数据。

备份保留

根据服务器上的备份保持期设置来保留备份。 可以选择 1 到 35 天的保持期，默认保持期为 7 天。 可以在服务器创建期间或以后通过使用 Azure 门户更新备份配置来设置保持期。

备份保持期控制执行时间点还原操作要回退的时间距离，因为它基于可用备份。 从恢复的角度来看，备份保留期也可以视为恢复时段。 在备份保留期间内执行时间点还原所需的所有备份都保留在备份存储中。 例如，如果备份保持期设置为 7 天，则可认为恢复时段是最近 7 天。 在这种情况下，将保留在过去 7 天内还原服务器所需的所有备份。 在备份保持期为 7 天的情况下，数据库快照和事务日志备份会存储过去 8 天内的内容（备份保持期前 1 天）。

备份存储成本

Azure Database for MySQL 灵活服务器最高可以提供 100% 的已预配服务器存储作为备份存储，不收取任何额外费用。 超出的备份存储使用量按每月每 GB 标准收费。 例如，如果为服务器配置了 250 GB 的存储空间，则可以为服务器备份提供 250 GB 的存储空间，而不另外收费。 如果每日备份使用量为 25GB，则最多可有 10 天的免费备份存储。 备份所消耗的存储量超过 250GB 将按照定价模型收费。

可以使用 Azure 门户中提供的 Azure Monitor 中的已使用的备份存储指标来监视服务器使用的备份存储。 已使用的备份存储指标表示根据为服务器设置的备份保持期保留的所有数据库备份和日志备份占用的存储总和。 无论数据库的总大小如何，如果服务器上的事务性活动繁重，都会导致备份存储使用率增加。 异地冗余服务器使用的备份存储量是本地冗余服务器的两倍。

控制备份存储成本的主要方法是设置适当的备份保持期。 可指定一个 1 到 35 天的保持期。

重要

如果从区域冗余高可用性配置中配置的数据库服务器进行备份，则备份发生在主数据库服务器上，因为快照备份的开销最小。

查看可用的完整备份

Azure 门户中的“备份和还原”边栏选项卡提供了在任何给定时间点可供你使用的完整备份的完整列表。 其中包括自动备份以及按需备份。 可以使用此边栏选项卡查看服务器保留期内所有可用完整备份的完成时间戳，并使用这些完整备份执行还原操作。 可用备份列表包括保留期内的所有备份、显示成功完成的时间戳、指示备份将保留多长时间的时间戳以及恢复操作。

还原

在 Azure Database for MySQL 灵活服务器中进行还原时，会根据原始服务器的备份创建新的服务器。 可以使用两种类型的还原：

  • 时间点还原：可以与任一备份冗余选项配合使用，所创建的新服务器与原始服务器位于同一区域。
  • 异地还原：只能在已将服务器配置为进行异地冗余存储的情况下使用，用于将服务器还原到异地配对区域或任何其他可使用灵活服务器的 Azure 支持区域。

服务器恢复的估计时间取决于以下几个因素：

  • 数据库的大小
  • 所涉及的事务日志数
  • 需要重新播放以恢复到还原点的活动数量
  • 还原到不同区域时的网络带宽
  • 目标区域中正在处理的并行还原请求数
  • 数据库的表中是否存在主键。 若要加快恢复速度，请考虑为数据库中的所有表添加主键。

注意

在进行时间点还原和异地还原后，启用了高可用性的服务器将变为非 HA（已禁用高可用性）。

时点还原

在 Azure Database for MySQL 灵活服务器中，执行时间点还原后，会通过灵活服务器在源服务器所在区域中的备份创建新的服务器。 它在创建时，使用原始服务器用于计算层、vCore 数、存储大小、备份保持期和备份冗余选项的配置。 此外，还会从源服务器继承标记和设置，例如虚拟网络和防火墙。 还原完成后，可以更改还原服务器的计算和存储层、配置和安全设置。

注意

还原操作完成后，有两个服务器参数重置为默认值（而不是从主服务器复制）

  • time_zone - 此值设置为默认值“SYSTEM”
  • event_scheduler - 对于 MySQL 版本 5.7 服务器，服务器参数 event_scheduler 会在备份开始后自动变为“OFF”，且服务器参数 event_scheduler 会在备份成功完成后重新变为“ON”。 在适用于 Azure Database for MySQL 灵活服务器的 MySQL 版本 8.0 中，event_scheduler 在备份期间不受影响。 为了确保运行更顺畅，建议使用 主要版本升级将 MySQL 5.7 服务器升级到版本 8.0。

多种情况下可以使用时间点还原。 常见的一些用例包括 -

  • 当用户意外删除数据库中的数据时
  • 用户删除重要表或数据库
  • 用户应用程序因为自身缺陷意外以错误数据覆盖正确数据。

可以通过 Azure 门户选择最新还原点、自定义还原点和最快还原点（使用完整备份还原）。

  • 最新还原点：最新还原点选项有助于在触发还原操作时将服务器还原到时间戳。 此选项可用于快速将服务器还原到最新状态。
  • 自定义还原点：通过此选项，可在为此灵活服务器定义的保持期内选择任何时间点。 此选项可用于在从用户错误中恢复的精确时间点还原服务器。
  • 最快还原点：通过此选项，用户能够以尽可能最快的速度将服务器还原到为此服务器定义的保留期内的给定日期。 通过选择已完成完整备份的还原时间点，即有可能实现最快还原。 此还原操作只能还原完整的快照备份，并不能保证还原或恢复日志，因此此操作才具有快速的特点。 建议为选择一个晚于最早还原时间点的完整备份时间戳，以便成功执行还原操作。

估计的恢复时间取决于几个因素，包括数据库大小、事务日志备份大小、SKU 的计算大小以及还原时间。 事务日志恢复是还原过程中最耗时的部分。 如果选择的还原时间更接近快照备份计划，则还原操作更快，因为事务日志应用程序最小。 若要估计服务器的准确恢复时间，强烈建议在你的环境中对其进行测试，因为它有太多的环境特定变量。

重要

若要还原配置了区域冗余高可用性的 Azure Database for MySQL 灵活服务器实例，那么还原的服务器与主服务器配置在相同的区域中，并以非 HA 模式部署为单一服务器。 有关灵活服务器，请参阅区域冗余高可用性。

重要

可在删除服务器后的 5 天内恢复已删除的 Azure Database for MySQL 灵活服务器资源。 有关如何还原已删除的服务器的详细指南，请参阅所述的步骤。 为了防止服务器资源在部署后遭意外删除或意外更改，管理员可以利用管理锁。

异地还原

可将服务器还原到其异地配对区域，只要服务在该区域可用即可（如果已将服务器配置为进行异地冗余备份），或者可以还原到任何其他可使用 Azure Database for MySQL 灵活服务器的 Azure 支持区域。 还原到任何非配对的 Azure 支持的区域（除 Brazil South、USGov Virginia 和 West US 3) 外）的功能称为“通用异地还原”。

当服务器因其所在的区域发生事故而不可用时，异地还原是默认的恢复选项。 如果区域中出现的大规模事件导致数据库应用程序不可用，可以根据异地冗余备份将服务器还原到任何其他区域中的服务器。 异地还原利用服务器的最新备份。 提取备份后，会延迟一段时间才会将其复制到其他区域中。 此延迟可能长达一小时，因此发生灾难时，会有长达 1 小时的数据丢失风险。

还可利用 Azure CLI 在已停止的服务器上执行异地还原。 请阅读通过 Azure CLI 还原 Azure Database for MySQL 灵活服务器，了解有关使用 Azure CLI 异地还原服务器的详细信息。

估计的恢复时间取决于若干因素，包括数据库大小、事务日志大小、网络带宽，以及在同一区域同时进行恢复的数据库总数。

注意

若要异地还原配置了区域冗余高可用性的 Azure Database for MySQL 灵活服务器实例，那么还原的服务器配置在异地配对区域和主服务器所在的同一区域中，并以非 HA 模式部署为单一 Azure Database for MySQL 灵活服务器实例。 请参阅 Azure Database for MySQL 灵活服务器的区域冗余高可用性。

重要

当主要区域关闭时，无法在相应的异地配对区域中创建异地冗余服务器，因为无法在主要区域中预配存储。 必须等待主要区域启动，以在异地配对区域中预配异地冗余服务器。 当主要区域关闭后，仍可以通过在还原门户体验中禁用“配置服务器”的“计算 + 存储”设置中的异地冗余选项，将源服务器异地还原到异地配对区域并还原为本地冗余服务器，以确保业务连续性。

执行还原后任务

从“最新还原点”或“自定义还原点”恢复机制还原后，都应执行以下任务，然后用户和应用程序才能重新运行 ：

  • 如果需要使用新的服务器来替换原始服务器，请将客户端和客户端应用程序重定向到新服务器。
  • 对于要进行连接的用户，请确保设置适当的服务器级防火墙规则和虚拟网络规则。
  • 确保设置适当的登录名和数据库级权限。
  • 根据需要配置警报。

长期保留（预览版）

Azure 备份和 Azure Database for MySQL 灵活服务器服务为 Azure Database for MySQL 灵活服务器实例构建了一个企业级的长期备份解决方案，最多可将备份保留 10 年。 可以独立使用长期保留，或者同时使用 Azure Database for MySQL 灵活服务器提供的自动备份解决方案（该方案包含最多 35 天保留期）。 自动备份是适用于操作恢复的快照备份，尤其是在想要从最新备份还原时。 长期备份可帮助你满足合规性需求和审核需求。 除了长期保留，该解决方案还提供以下功能：

  • 由客户控制、计划的按需备份
  • 从名为备份中心的单个管理窗格中管理和监视跨服务器、资源组、位置、订阅和租户的所有与备份相关的操作和作业。
  • 备份存储在单独的安全域和容错域中。 如果源服务器或订阅受到损坏，备份在备份保管库中（在 Azure 备份托管存储帐户中）都会保持安全。

限制和注意事项

  • 在预览版中，LTR 还原目前可用作存储帐户的 RestoreasFiles。 未来将添加 RestoreasServer 功能。
  • 目前不支持通过 Azure CLI 创建和管理 LTR。

有关执行长期备份的详细信息，请访问操作指南

按需备份和导出（预览版）

Azure Database for MySQL 灵活服务器现在能够触发服务器的按需即时物理备份，并将其导出到 Azure 存储帐户（Azure blob 存储）。 导出后，这些备份可用于数据恢复、迁移和冗余。 这些导出的物理备份文件可用于还原回本地 MySQL 服务器，以帮助满足组织的审核/合规性/存档需求。 该功能目前处于公共预览阶段，仅适用于公有云区域。

有关导出备份的详细信息，请访问操作指南

常见问题解答 (FAQ)

  • 如何备份服务器？

    默认情况下，Azure Database for MySQL 灵活服务器启用自动备份整个服务器（包含创建的所有数据库），且保持期默认为 7 天。 还可以使用按需备份功能触发手动备份。 手动执行备份的其他方法是使用社区工具，例如此处介绍的 mysqldump 或此处介绍的 mydumper。 若要将 Azure Database for MySQL 灵活服务器实例备份到 Blob 存储，请参阅我们的技术社区博客将 Azure Database for MySQL 灵活服务器备份到 Blob 存储。

  • 能否将自动备份配置为长期保留？

    否，目前仅支持最长 35 天的自动备份保留。 可以执行手动备份，然后使用这些备份来满足长期保留要求。

  • 服务器的备份时段是什么？ 是否可以自定义它？

    第一次快照备份在创建服务器后立即进行计划。 每天进行一次快照备份。 事务日志备份每五分钟进行一次。 备份时段本质上由 Azure 管理，无法自定义。

  • 我的备份是否加密？

    在查询执行过程中创建的所有 Azure Database for MySQL 灵活服务器数据、备份和临时文件都使用 AES 256 位加密进行加密。 存储加密始终处于启用状态，无法禁用。

  • 是否可以还原单个/数个数据库？

    不支持还原单个/数个数据库或表。 若要还原特定数据库，请执行时间点还原，然后提取所需的表或数据库。

  • 我的服务器在备份时段内是否可用？

    是的。 备份是基于快照的联机操作。 快照操作只需几秒钟，不会影响生产工作负载，可确保服务器的高可用性。

  • 在为服务器设置维护时段时，是否需要考虑备份时段？

    否，备份作为托管服务的一部分在内部触发，对托管维护时段没有影响。

  • 我的自动备份存储在何处，如何管理其保留期？

    Azure Database for MySQL 灵活服务器可自动创建服务器备份并将其存储在用户配置的本地冗余存储或异地冗余存储中。 无法导出这些备份文件。 默认的备份保留期为七天。 可以选择将数据库备份配置为 1 到 35 天。

  • 如何验证备份？

    验证成功完成备份的可用性的最佳方法是在“备份和还原”边栏选项卡中查看在保留期内进行的全自动备份。 如果备份失败，则不会在可用备份列表中列出该备份，并且备份服务会每隔 20 分钟尝试创建一次备份，直到创建备份成功。 这些备份失败的原因在于服务器上繁重的事务生产负载。

  • 在哪里可以查看备份使用情况？

    在 Azure 门户中“监视”选项卡下的“指标”部分中，可以找到已使用备份存储指标，该指标有助于监视备份的总使用量。

  • 如果删除服务器，我的备份会发生什么情况？

    如果删除服务器，则属于该服务器的所有备份也会被删除且不可恢复。 为了防止服务器资源在部署后遭意外删除或意外更改，管理员可以使用管理锁。

  • 还原服务器时备份会发生什么情况？

    如果还原服务器，则始终会导致创建使用原始服务器的备份还原的全新服务器。 原始服务器的旧备份不会复制到新还原的服务器，会与原始服务器一起保留。 但是，对于新创建的服务器，将在创建服务器后立即计划第一个快照备份，该服务可确保按照配置的服务器保留期执行每日自动备份并存储。

  • 如何对备份的使用进行收费和计费？

    Azure Database for MySQL 灵活服务器最高可以提供 100% 的已预配服务器存储作为备份存储，不收取任何额外费用。 超出的任何备份存储使用量根据定价模型按每月每 GB 标准收费。 除了服务器上的事务活动（它们直接影响所用备份存储总量）之外，备份存储计费还受所选备份保持期和备份冗余选项的控制。

  • 如何为已停止的服务器保留备份？

    不会对已停止的服务器执行任何新备份。 停止服务器时，将保留所有旧备份（在保留时段内），直到服务器重启，之后，活动服务器的备份保留期由其备份保留时段控制。

  • 如何为已停止的服务器的备份计费？

    服务器实例停止后，你需要为预配的存储（包括预配的 IOPS）和备份存储（在指定保留时段内存储的备份）付费。 免费备份存储仅限于预配数据库的大小，并且仅适用于活动服务器。

  • 如何保护我的备份数据？

    Azure Database for MySQL 灵活服务器通过在配置的保持期内阻止任何可能导致恢复点丢失的操作来保护备份数据。 在保持期内进行的备份只能出于还原目的读取，并在保持期后删除。 此外，Azure Database for MySQL 灵活服务器中的所有备份都使用针对静态存储数据的 AES 256 位加密进行加密。

  • 时间点还原 (PITR) 操作如何影响 IOPS 使用情况？

    在 Azure Database for MySQL 灵活服务器中执行 PITR 操作期间，会创建一个新服务器，并会将数据从源服务器的存储复制到新服务器的存储。 此过程会导致源服务器上的 IOPS 使用量增加。 IOPS 使用量的这种增加是正常现象，并不表示源服务器或 PITR 操作有任何问题。 PITR 操作完成后，源服务器上的 IOPS 使用量将恢复到正常水平。

  • 如何还原我的服务器？ Azure 门户支持对所有服务器进行时间点还原，使用户可以还原到最新还原点或自定义还原点。 若要从使用 mysqldump/myDumper 执行的备份手动还原服务器，请参阅使用 myLoader 还原数据库。

  • 为什么还原需要太多时间？

    服务器恢复的估计时间取决于以下几个因素：

    • 数据库的大小。 在恢复过程中，需要从上一个物理备份中解冻数据库，因此恢复所需的时间将与数据库的大小成正比。
    • 需要重新播放才可恢复的事务活动的活动部分。 恢复可能需要较长时间，具体取决于上一个成功检查点的其他事务活动。
    • 还原到不同区域时的网络带宽。
    • 目标区域中正在处理的并行还原请求数。
    • 数据库的表中是否存在主键。 若要加快恢复速度，请考虑为数据库中的所有表添加主键。

  • 修改会话级别数据库变量是否会影响还原？

    在 MySQL 客户端会话中修改会话级变量和运行 DML 语句可能会影响 PITR（时间点还原）操作，因为这些修改不会记录在用于备份和还原操作的二进制日志中。 例如，foreign_key_checks 就是这样一个会话级变量，如果禁用该变量来运行违反外键约束的 DML 语句，将导致 PITR（时间点还原）失败。 这种情况的唯一解决方法是选择一个早于 foreign_key_checks 禁用时间的 PITR 时间。 建议不要修改任何会话变量，以实现成功的 PITR 操作。

后续步骤