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

文章插图
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