构建数据库灾难恢复计划的注意事项

在一个理想的世界里，我们设计的复杂系统可以无限期运行，不存在停机风险。然而，现实并非如此，因此了解如何从故障中恢复是不可避免的必要技能。
本文将讨论一些关键注意事项和最佳实践，以确保当灾难发生时，你能够快速且高效地恢复数据库。

高可用性与灾难恢复

高可用性（HA）和灾难恢复（DR）是两个与停机相关的紧密关联的概念。HA指的是设计系统时确保其能够在故障中继续运行。例如，在一个MySQL集群中，主要数据库服务器的数据被复制到三个服务器。如果主数据库服务器宕机，系统可以在几秒钟内自动选举新的主节点并重新路由流量。虽然部分用户可能注意到短暂的中断，但大多数用户不会受到影响。这种故障转移过程得益于数据复制技术，我们稍后会详细讨论这一点。
另一方面，DR专注于从可能对业务产生更广泛且更长时间影响的大故障中恢复。它涉及实施策略和程序，在灾难性事件后恢复数据库及其相关服务。与旨在最小化停机时间并确保连续运行的HA不同，DR关心的是总体恢复过程，以及尽可能快地恢复正常的业务运作。
通过结合HA和DR的实践，组织可以构建弹性数据库系统，能够承受轻微和重大中断，确保数据的可用性和完整性。

定义恢复目标

每个系统都会因为各种原因不可避免地发生故障，因此提前考虑这些情况并为公司设定明确的恢复目标是明智的。

什么是恢复点目标（RPO）？

恢复点目标（Recovery Point Objective，RPO）指的是在灾难发生时，企业能够接受的最大数据丢失量。通过设定RPO，你明确了在灾难发生并系统恢复上线时，数据丢失的最大可接受范围（以小时、分钟或秒为单位）。将你的备份策略与RPO对齐至关重要，以确保不超过可接受的数据丢失范围。
例如，如果你为数据库配置了每日备份，并且你的RPO是以小时计算的，那么如果上一次备份是23小时前完成的，就可能达不到你的RPO目标。因此，需要慎重考虑备份频率和保留策略，以有效满足RPO要求。

什么是恢复时间目标（RTO）？

恢复时间目标（Recovery Time Objective，RTO）代表恢复特定停机事件的时间目标。一旦设定了更短的RTO，就表明你的团队需要更快响应以恢复系统的全面功能。RTO通常以小时或分钟为单位，是评估DR计划效果的重要指标，同时也是企业内部成员之间设定期望值的重要工具。
这些目标使得团队在灾难恢复时能够一致行动。RPO和RTO越小，灾难恢复解决方案就越复杂和昂贵。因此，这是一种在投入成本与停机时间之间的平衡艺术。

数据库是有状态的，而代码是无状态的

有状态指的是系统的操作和功能直接依赖于其执行的之前动作。代码通常是无状态的，运行代码的进程不需要依赖底层的特定数据。例如，如果你的web应用服务器发生故障并且宕机，可以很轻松地切换到另一台服务器，重新路由流量，然后恢复业务运作。
然而，数据库的情况不同。数据库是有状态的，因为从创建以来，数据库中的数据是所有事务处理的结果。如果托管MySQL数据库的服务器发生崩溃，不能简单地用一个新的MySQL服务器替换它。如果用户（或者应用）丢失了所有数据，即使应用重新上线，也是没用的。正因如此，数据库灾难恢复需要更细致入微的规划和关注，这是解决应用问题时所不需要的。

MySQL灾难恢复功能

MySQL复制

复制功能支持将数据复制到多个MySQL服务器。这项功能不仅能使数据库具有高可用性，还能在灾难发生时快速恢复数据。例如，如果主要的数据库服务器发生故障，在其他可用区或区域有一个复制的数据库副本，可以迅速恢复服务。在典型的设置中，一个服务器处理读写负载（主节点），其余服务器（副本节点）仅处理只读负载。
MySQL支持两种复制模式：异步模式和半同步模式。在默认半同步模式下，主服务器提交事务后等待至少一个副本确认收到该信息。而异步模式允许主节点在提交事务后立即响应客户端，而无需等待副本的确认。
半同步模式适用于低延迟场景，例如位于同一区域的服务器。而异步复制模式更适合距离较远的场景，但可能导致远程区域的数据滞后，因为主节点不等待副本确认事务。此外，由于异步模式的数据副本可能稍微落后，但这通常是一种合理的权衡，因为等待主区域恢复上线可能并不实际。

数据库备份

制定强大的备份策略是实施有效灾难恢复的关键。备份分为两种类型：逻辑备份和物理备份。逻辑备份由能够从头创建数据库的SQL语句组成，而物理备份则是磁盘上实际文件的副本。两者都表示某一时间点上的数据库状态。
需要权衡何时进行全量备份与增量备份，以及它们的适用场景。全量备份是数据库当前状态的完整副本，而增量备份则记录两次备份间的变化。增量备份通过二进制日志进行，需要按备份生成时间的顺序进行恢复，以获得完整版本的数据库。
备份过程可能对服务器资源造成压力，尤其是大规模数据库，可能影响应用的响应性。通过复制功能，可以使用副本节点来处理只读负载，从而减轻主服务器负担。
在PlanetScale，我们使用只读副本进行数据库备份，并在备份之前使用备份专用副本验证备份的可用性。这样可以确保客户在灾难发生时，可以使用可靠的备份进行恢复。

构建数据库灾难恢复计划

每个公司的灾难恢复计划都不尽相同，因此以下是制定计划时需要考虑的一些要点：

定义RPO和RTO确定RPO与RTO非常重要。这将帮助你了解应该采取的措施以达到目标，以及达到目标所需的成本。这一过程应与公司领导层一起完成，使他们了解停机成本。此外，让其他关键成员参与，以确保对灾难恢复计划的全局共识。
使用跨区域复制加速恢复将流量重新路由到其他区域的活动数据库服务器通常比从备份恢复整个数据库要快得多。此外，复制延迟造成的数据丢失可能会比恢复备份时的数据丢失更少。
优先恢复关键系统并非所有基础架构或应用都具有同等重要性。一些系统及其关联数据库比其他系统更重要。首先定义哪些系统至关重要，哪些次要。在恢复时明确优先级，确保关键系统尽快恢复上线。你可以根据系统对业务的重要性为其指定专属RPO和RTO。
以收入损失为指标公司建系统的最终目标要么是节约成本，要么是创造收入。因此在制定灾难恢复计划时，需要明确停机导致的收入损失，并据此定义RPO和RTO优先级，帮助快速恢复优先级高的系统。这也有助于为灾难恢复计划所需资源争取支持。
自动化恢复过程人为错误在压力下恢复关键业务系统时更容易发生。自动化恢复过程可以确保灾难恢复是可重复的，并减少人为错误的概率。这不仅让流程更快更高效，还可以确保恢复步骤每次都保持一致，团队中的任何成员都能执行恢复，而不只是依赖经验丰富的人。
定期测试计划检验灾难恢复计划最有效的方法是定期测试。频繁的测试可以帮助你掌握系统恢复的耗时及其对业务的影响。此外，还可以验证现有资源是否足以达到RPO和RTO目标，同时了解是否需要更新计划或纳入新系统。

备份验证也是灾难恢复的关键部分。仅有备份软件报告备份成功还远远不够；毕竟，真正的备份价值在于能否成功恢复。如果备份出现损坏或配置错误，可能导致灾难来临时产生毁灭性后果，从而对业务造成重大损失。
通过自动化并定期测试恢复流程，确保你的备份能够在最需要的时候成功恢复。亚马逊将这些测试活动称为“游戏日”，通过模拟故障来测试恢复流程。