譯者 | 李睿
審校 | 孫淑娟
災難恢復（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存儲節點。
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）災難恢復解決方案比較在下表中，對本文中提到的容災解決方案進行了比較：
經過30多年的發展和幾個不同的發展階段，災難恢復技術如今已經進入了多活階段。
而使用無共享架構，TiDB等分布式數據庫結合了多副本技術和日志復制工具，將數據庫容災帶入多區域時代。
原文鏈接：https://dzone.com/articles/how-the-disaster-recovery-solutions-for-cloud-data
