有关使用 Azure Database for MySQL 灵活服务器确保业务连续性的概述
Azure Database for MySQL 灵活服务器支持业务连续性功能，可在发生计划内和计划外中断时保护数据库。 自动备份和高可用性等功能可实现不同级别的故障保护，具有不同的恢复时间和数据丢失情况。 在构建应用程序以防止故障时，应考虑每个应用程序的恢复时间目标 (RTO) 和恢复点目标 (RPO)。 RTO 是指故障时间容错，RPO 是指数据库服务中断后的数据丢失容错。
下表说明了 Azure Database for MySQL 灵活服务器提供的功能。
| 功能 | 说明 | 限制 |
|---|---|---|
| 备份和恢复 | 该服务自动执行数据库文件的每日备份，并连续备份事务日志。 备份可以保留 1 至 35 天。 可将数据库服务器还原到备份保留期内的任何时间点。 恢复时间取决于要还原的数据的大小 + 执行日志恢复的时间。 有关更多详细信息，请参阅在 Azure Database for MySQL 灵活服务器中进行备份和还原。 | 备份数据保留在该区域中 |
| 本地冗余备份 | 该服务会自动并安全地将备份存储在某区域的同一可用性区域的本地冗余存储中。 本地冗余备份在主要区域中的单个物理位置内复制服务器备份数据文件三次。 本地冗余备份存储可在一年中提供至少 99.999999999%（11 个 9）的对象持久性。 有关更多详细信息，请参阅在 Azure Database for MySQL 灵活服务器中进行备份和还原。 | 适用于所有区域 |
| 异地冗余备份 | 该服务备份可以在创建时配置为异地冗余。 启用异地冗余会复制主要区域的配对区域中的服务器备份数据文件，以提供区域复原能力。 异地冗余备份存储可在一年中提供至少 99.99999999999999%（16 个 9）的对象持久性。 有关更多详细信息，请参阅在 Azure Database for MySQL 灵活服务器中进行备份和还原。 | 适用于所有 Azure 配对区域 |
| 区域冗余高可用性 | 该服务可部署为高可用性模式，这会在一个区域中的两个不同的可用性区域中部署主服务器和备用服务器。 区域冗余高可用性可防止区域级故障，还有助于减少计划内和计划外故障事件期间的应用程序故障时间。 主服务器中的数据会同步地复制到备用副本。 在发生任何停机事件期间，数据库服务器会自动故障转移到备用副本。 有关更多详细信息，请参阅Azure Database for MySQL 灵活服务器中的高可用性概念。 | 在“常规用途”和“业务关键”计算层中受支持。 仅可在提供多个区域的区域中使用。 |
| 高级文件共享 | 数据库文件存储在高度持久且可靠的 Azure 高级文件共享中，这些文件共享提供了数据冗余，将 3 个副本存储一个可用性区域中，并且具有数据自动恢复功能。 请参阅高级文件共享，了解更多详细信息。 | 存储在可用性区域中的数据 |
缓解计划内停机
下面是一些产生故障时间的计划内维护场景：
| 方案 | 处理 |
|---|---|
| 计算缩放（用户） | 在执行计算缩放操作时，将使用缩放的计算配置来预配新的灵活服务器。 在现有的数据库服务器中，将允许处于活动状态的检查点完成，客户端连接将排空，所有未提交的事务将取消，然后将关闭该服务器。 接下来存储会连接到新服务器，而数据库也会启动，该数据库在接受客户端连接前会根据需要执行恢复。 |
| 新软件部署 (Azure) | 新功能的推出或 bug 修复作为服务的计划内维护的一部分自动发生，你可以安排这些活动发生的时间。 有关详细信息，请参阅文档并检查你的门户 |
| 次要版本升级 (Azure) | Azure Database for MySQL 灵活服务器会自动将数据库服务器修补到 Azure 确定的次要版本。 这是在服务的计划内维护过程中发生的。 这会导致短暂的停机（以秒为单位），并且会自动重启装有新次要版本的数据库服务器。 有关详细信息，请参阅文档并检查你的门户。 |
如果为灵活服务器配置了“区域冗余高可用性”，那么在没有故障转移的情况下，灵活服务器将先在备用服务器上执行操作，然后在主服务器上操作。 有关更多详细信息，请参阅Azure Database for MySQL 灵活服务器中的高可用性概念。
缓解计划外停机
意外的故障（包括基础硬件故障、网络问题和软件 bug）可能会产生计划外故障时间。 如果数据库服务器意外关闭（且已配置高可用性 [HA]），则会激活备用副本。 如果没有，则会自动预配新的数据库服务器。 虽然计划外故障无法避免，但灵活服务器可以通过在数据库服务器和存储层上自动执行恢复操作来减少故障时间，无需人工干预。
计划外停机：故障场景和服务恢复
下面是一些计划外故障场景和恢复过程：
| 方案 | 恢复过程 [非 HA] | 恢复过程 [HA] |
|---|---|---|
| 数据库服务器故障 | 如果数据库服务器由于某些基础硬件故障而关闭，则会丢弃处于活动状态的连接，并中止任何正在进行的事务。 Azure 会尝试重启数据库服务器。 如果成功，则会执行数据库恢复。 如果重启失败，则会尝试在另一物理节点上进行数据库服务器重启。 恢复时间 (RTO) 取决于各种因素，包括发生故障时的活动（例如大型事务），以及需在数据库服务器启动过程中执行的恢复操作的量。 RPO 为零，因为已提交的事务预计不会丢失数据。 所构建的使用 MySQL 数据库的应用程序需要能够检测并重试丢弃的连接和失败的事务。 当应用程序重试时，连接将定向到新创建的数据库服务器。 其他可用选项将从备份还原。 可以从配对区域使用 PITR 或异地还原。 “PITR”：RTO：可变，RPO=0 秒 异地还原：RTO：可变 RPO < 1 小时。 还可以将只读副本用作 DR 解决方案。 可以停止复制（这会使只读副本变为独立的可读写副本），然后将应用程序流量重定向到此数据库。 在大多数情况下，RTO 为几分钟，RPO < 1 小时。 在某些情况下，RTO 和 RPO 可能会高得多，具体取决于各种因素（包括站点间的延迟，要传输的数据量，以及最重要的：主数据库写入工作负荷）。 |
如果检测到数据库服务器故障或不可恢复错误，则会激活备用数据库服务器，从而减少故障时间。 有关更多详细信息，请查看 HA 概念页面。 RTO 应为 60-120 秒，RPO=0。 注意：恢复过程 [非 HA] 的选项也适用于此处。 |
| 存储故障 | 对于任何与存储相关的问题（例如磁盘故障或物理块损坏），应用程序看不到任何影响。 由于数据存储在三个副本中，因此将由未发生故障的存储提供数据的副本。 块损坏会自动修复。 如果丢失了数据的副本，则会自动创建数据的新副本。 在极少数或最差的情况下，如果所有副本都已损坏，我们可以使用异地还原（配对区域）。 RPO 为 < 1 小时，RTO 会有所不同。 还可将只读副本用作 DR 解决方案，如上所述。 |
对于此方案，选项与恢复过程[非 HA] 相同。 |
| 逻辑/用户错误 | 在发生用户错误（例如，意外删除了表或错误地更新了数据）后进行的恢复涉及到执行时间点恢复 (PITR)，方法是将数据还原并恢复到发生错误之前的那个时间点。 在删除服务器后的 5 天内，可以恢复已删除的灵活服务器资源。 有关如何还原已删除的服务器的详细指南，[请参阅所述的步骤] (../flexible-server/how-to-restore-dropped-server.md)。 为了防止服务器资源在部署后遭意外删除或意外更改，管理员可以使用管理锁。 |
这些用户错误不受高可用性保护，这是由于所有用户操作均已复制到备用服务器。 对于此方案，选项与恢复过程相同[非 HA] |
| 可用性区域故障 | 虽然这是一个很少见的事件，但如果想要从区域级别的故障中恢复，则可以执行从到配对区域的异地还原。 RPO 为 < 1 小时，RTO 会有所不同。 还可以通过在其他可用性区域中创建副本，将“只读副本”用作 DR 解决方案。 RTO\RPO 类似于上面所述的内容。 |
如果启用了区域冗余 HA，则灵活服务器将自动故障转移到备用站点。 有关更多详细信息，请参阅Azure Database for MySQL 灵活服务器中的高可用性概念。 RTO 应为 60-120 秒，RPO=0。 其他可用选项将从备份还原。 可以从配对区域使用 PITR 或异地还原。 “PITR：” RTO：可变，RPO=0 秒 异地还原：RTO：可变 RPO <1 小时 注意：如果启用了同区域 HA，则这些选项与恢复过程 [非 HA] 的选项相同。 |
| 区域故障 | 虽然这是一个罕见事件，但如果想从区域级故障中恢复，可以通过使用同一订阅下可用的最新异地冗余备份创建新服务器来执行数据库恢复，以获取最新数据。 会有一个新的灵活服务器部署到所选区域。 还原所需的时间取决于以前的备份和要恢复的事务日志数量。 在大多数情况下，RPO 为 < 1 小时，RTO 会有所不同。 | 对于此方案，选项与恢复过程[非 HA] 相同。 |
要求和限制
区域数据驻留
默认情况下，Azure Database for MySQL 灵活服务器不会将客户数据移出部署的区域或存储到部署区域以外的区域。 但是，客户可以选择启用异地冗余备份或设置跨区域副本，以便在另一个区域存储数据。