云计算数据库的灾难恢复解决方案是如何演进的？

高可用性和灾难恢复的测量

每个灾难都是独一无二的，因此容错目标（FTT）描述了系统能够承受的最大灾难范围。通常使用的容错目标（FTT）是区域级别，它表示灾难已经影响到州或城市等地理区域。

2、灾难恢复发展简史

数据库的灾难恢复技术经历了备份和恢复、主备和多活三个阶段。

（1）备份和恢复

在灾难恢复的早期阶段，数据库利用数据块和事务日志为完整数据和增量数据创建备份。如果发生灾难，则从备份和应用程序事务日志恢复数据库。

近年来，公共云数据库服务将存储复制与传统数据库备份技术相结合，提供基于快照的跨区域自动恢复备份。这种方法定期从源区域的数据库生成快照，并将快照文件复制到目标区域。如果源区域崩溃，则从目标区域恢复数据库，服务将会继续。这种解决方案的恢复点目标(RPO)和恢复时间目标(RTO)可能长达几个小时，因此它最适合没有严格可用性需求的应用程序。

备份和恢复的灾难恢复

（2）主备

数据库集群标志着开发的第二个阶段。在集群中，主节点读取和写入数据。一个或多个备份节点接收事务日志并应用它们，提供具有一定延迟的读取功能。

主备的灾难恢复

尽管这个解决方案涉及到集群的概念，但它仍然基于一个整体数据库。可扩展性仅限于读操作，不能扩展写操作。当然与前一代解决方案相比，其恢复时间目标(RTO)减少到几分钟，恢复点目标(RPO)减少到几秒。

Amazon Aurora使用跨区域读副本的逻辑复制，是建立在该技术上的早期云数据库服务之一。

具有跨区域读副本的Aurora逻辑复制

近年来，Aurora在这一设计的基础上提供了全球数据库服务。该服务通过存储复制技术，将数据从源区域异步复制到目的区域。如果源区域出现故障，服务可以立即切换到备份集群。恢复时间目标(RTO)可以减少到几分钟，恢复点目标(RPO)不到一秒。

（3）多活灾难恢复

在多活灾难恢复中，一个数据库为同一份数据副本提供至少三个读和写服务节点，并且数据库可以根据工作负载向外或向内扩展。这种功能背后的需求来自广泛的互联网规模应用程序，这些应用程序需要更高的性能、更低的延迟、更高的可用性、弹性扩展性和数据库的弹性。

传统的分片数据库基于一个或多个列共享数据，形成了多活。分片解决方案通过事务日志复制实现灾难恢复。例如，谷歌公司曾经维护过一个非常大的MySQL分片系统。这个解决方案提供了某种程度的可扩展性，但不能随着碎片的增加而提高灾难恢复能力。其性能将显著下降，维护成本将大幅上升。因此，分片是多活的过渡解决方案。

近年来，基于Raft或Paxos共识协议的无共享数据库发展迅速。他们解决了以上提到的可扩展性和可用性挑战。多活的主要参与者包括TiDB和CockroachDB。他们的数据库及其灾难恢复技术使大多数遗留数据库和关系数据库服务（RDS）过时。

3、具有分布式数据库的多活灾难恢复

以下了解应用于分布式数据库的多活灾难恢复。例如，TiDB是一个开源的、高可用性的分布式数据库。它将每个表或分区划分为较小的TiDB区域，并将这些TiDB区域中的数据的多个副本存储在不同的TiKV节点上。这就是所谓的数据冗余。TiDB采用Raft共识协议，因此当数据发生更改时，只有在事务日志同步到大多数数据副本时才返回事务提交。这极大地提高了数据库恢复点目标(RPO)。事实上，在大多数情况下恢复点目标(RPO)是0。这确保了数据的一致性。此外，TiDB的架构将其存储引擎和计算引擎分离开来。这允许用户根据工作负载的变化扩展TiDB节点和TiKV存储节点。

TiDB的存储架构

（1）典型的多区域容灾解决方案

下图显示了TiDB如何交付典型的多区域灾难恢复解决方案。

TiDB的多区域容灾解决方案

以下是TiDB容灾架构的关键术语：

TiDB区域：TiDB的调度和存储单元。区域：两个地点或城市。可用性区域（AZ）：独立的高可用性（HA）分区。在大多数情况下，可用性区域（AZ）是一个区域中相距较近的两个数据中心或城市。 L：Raft组的Leader副本。 F：Raft组中的Follower副本。

在上图中，每个区域包含数据的两个副本。它们位于不同的可用性区域（AZ）中，整个集群跨越三个区域。区域1通常处理读写请求。区域2用于在区域1发生灾难后的故障转移，它还可以处理一些对延迟不敏感的读负载。区域3是保证即使在区域1完成时仍能达成共识的副本。这种典型的配置称为“2-2-1”架构。这种架构不仅确保了灾难恢复，而且为业务提供了多活能力。在这一架构中：

最大的容错目标可以位于区域级别。可以扩展写作能力。恢复点目标(RPO)为0。恢复时间目标(RTO)可以设置为1分钟甚至更短。

许多分布式数据库供应商经常向他们的用户推荐这种架构作为灾难恢复解决方案。例如，CockroachDB推荐他们的3-3-3配置来实现区域级灾难恢复；Spanner为多区域部署提供2-2-1配置。但是，当区域1和2同时不可用时，这一解决方案不能保证高可用性。一旦区域1完全关闭，如果区域2上的任何一个存储节点出现问题，则可能会导致系统性能下降，甚至数据丢失。如果需要多区域级别的容错目标（FTT），或者需要严格的系统响应时间，则仍然需要将这一解决方案与事务日志复制技术相结合。

（2）使用变更数据捕获增强的多区域灾难恢复

TiCDC是TiDB的增量数据复制工具。它获取TiKV节点上的数据变化，并与下游系统同步。TiCDC具有与事务日志复制系统类似的架构，但它具有更强的可扩展性，并且在灾难恢复场景中与TiDB协同工作良好。

以下配置包含两个TiDB集群。区域1和区域2共同组成集群1，这是一个由5个副本组成的集群。区域1包含两个副本，用于提供读写操作，区域2包含两个副本，用于在区域1发生灾难时进行快速故障转移。区域3包含一个用于在Raft组中达到quorum的副本。区域3中的集群2作为灾难恢复集群。它包含三个副本，以便在区域1和区域2发生灾难时提供快速故障转移。TiCDC处理两个集群之间数据更改的同步。这种增强的架构可以称为2-2-1:1。

使用TiCDC的TiDB多区域灾难恢复

这种看似复杂的配置实际上具有更高的可用性。它可以实现多区域级别的最大容错目标，恢复点目标(RPO)以秒为单位，恢复时间目标(RTO)以分钟为单位。对于单个区域，如果完全不可用，恢复时间目标(RTO)为0。

（3）灾难恢复解决方案比较

在下表中，对本文中提到的容灾解决方案进行了比较：

4、结语

经过30多年的发展和几个不同的发展阶段，灾难恢复技术如今已经进入了多活阶段。

而使用无共享架构，TiDB等分布式数据库结合了多副本技术和日志复制工具，将数据库容灾带入多区域时代。

原文链接：https://dzone.com/articles/how-the-disaster-recovery-solutions-for-cloud-data