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

译者 | 李睿
审校 | 孙淑娟
灾难恢复（DR）是企业级数据库的核心功能。数据库供应商一直在寻找改进灾难恢复的方法，而在过去的10年里，数据库灾难恢复也出现了重大的创新。
本文简要介绍数据库灾难恢复的发展历史，重点介绍了基于云计算的分布式数据库中的灾难恢复（DR）和高可用性（HA）的创新。
1、测量高可用性和灾难恢复高可用性（HA）和灾难恢复（DR）的目标是保持系统在操作级别上正常运行。它们都试图消除系统中的单点故障，并使故障切换或恢复过程实现自动化。
高可用性（HA）通常由系统每年运行的时间百分比来衡量。灾难恢复的重点是在灾难发生之后使系统恢复服务，使数据的损失最小化。这是由两个指标来衡量的：恢复所需的时间或恢复时间目标(RTO)，以及数据量的丢失或恢复点目标(RPO) 。而恢复点目标(RPO)和恢复时间目标(RTO)应该尽可能降低。

文章插图
高可用性和灾难恢复的测量
每个灾难都是独一无二的，因此容错目标（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存储节点。