云計算數據庫的災難恢復解決方案是如何演進的？

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。