非同步容災,AntDB的業務不間斷資料恢復方案

亞信AIDB資料庫發表於2022-06-20

當業務對資料庫進行了誤操作,導致了資料的丟失或其他問題的發生。此時,雖然可以通過備份恢復或資料閃回等方式能夠對資料庫進行恢復,但是該過程可能會導致業務出現較長時間的中斷,最終影響業務系統的穩定性。

在這種場景下,AntDB資料庫提供了延遲複製的容災方案,可以供業務進行快速恢復,給出了一種新的資料恢復解決方案,本文對這種延遲複製的容災方案進行了探索。


關鍵詞 :同步複製;非同步複製;延遲複製;資料庫引數



01

資料庫容災概述


在業務誤刪除資料的情況下,可以使用AntDB資料庫提供的延遲複製的容災方案,對誤刪除資料進行快速恢復, 保證業務系統的穩定執行



02

AntDB延遲複製的原理


本章節介紹了複製的基本原理、延遲複製的基本原理、 AntDB資料庫延遲複製 的適用場景。


複製的基本原理


線上執行的資料庫,通常都會採用高可用部署來確保資料庫的穩定執行。AntDB資料庫在進行高可用部署的時候,可支援如下兩種模式:


  • 同步複製高可用:一個事務的所有修改都被傳送到一臺或者多臺同步後備伺服器後,AntDB資料庫才會認為該事務正常執行。


圖1:AntDB同步複製原理


  • 非同步複製高可用 :一個事務在主庫上執行成功後 (不管後備伺服器是否接收到了該事務相關的資訊) ,AntDB資料庫就認為該事務正常執行。


圖2:AntDB非同步複製原理


延遲複製的基本原理


預設情況下, 備庫 非同步複製獲取到了資料檔案之後,立即回放接收到的資料檔案;保證 主庫 上已經提交的事務能夠在備庫上也提交,從而保證 主備資料的一致性


延遲複製的功能,是建立在非同步複製的基礎上支援的功能;可以通過配置相應的引數,來控制資料檔案何時在備庫中進行回放。


以股市T+1業務為例介紹延遲備庫:

  • 股市業務中T+1:T時間點交易結束,資金需要延遲1個交易日才會到賬(假設下一個交易日是工作日)。

  • 延遲備庫中T+N:T時間點交易結束,備庫需要延遲N時間後才會在備庫進行資料檔案的回放。

  • # 主庫:事務提交時間為T

  • # 延遲備庫:事務提交時間為T+N

具體的AntDB資料庫處理流程,可以參考下圖:


圖3:AntDB延遲複製的原理


資料庫延遲複製的適用場景


通過上述描述,可以獲得 延遲複製 的適用場景:

  • 巨量資料庫備份恢復的補充方案,可以有效降低成本。

  • 若主庫T時間點誤操作(僅指DML操作,對於Truncate、Drop等DDL無效),可以在N時間段內完成T時間點內的資料恢復,這是因為備庫延遲至T+N時間點,才會開始WAL日誌流重做。



延遲複製災備方案的示例


本章節介紹了 環境資訊 搭建主備複製 主備資料一致性驗證 延遲複製的設定 延遲複製的驗證


環境資訊

在如下環境中部署AntDB高可用環境:



搭建主備複製

1.10.21.13.207構建主庫:


2. 10.21.13.208構建備庫:


3. 檢查複製狀態

圖4:10.21.13.207複製狀態檢查結果

圖5:10.21.13.208複製狀態檢查結果


結論:AntDB資料庫主備複製關係已經搭建正常。



主備資料一致性驗證

10.21.13.207:

圖6:10.21.13.207資料的查詢

圖7:10.21.13.208資料的查詢


結論:主備資料保持一致。



延遲複製的設定

10.21.13.208 上通過設定AntDB資料庫引數 recovery_min_apply_delay 來設定延遲複製。


圖8:10.21.13.208上設定延遲複製引數


結論:AntDB資料庫延遲複製引數已經設定生效。



延遲複製的驗證


3.5.1 DML 的驗證

10.21.13.207進行DML的驗證:


圖9:10.21.13.207上進行DML的驗證


10.21.13.208進行DML的驗證:

圖10:10.21.13.208上進行DML的驗證


結論:主庫上的SQL瞬間執行完成;備庫的資料日誌回放,正常按照延遲複製引數進行的(1min)。



3.5.2 DML誤操作時的恢復

1. 10.21.13.207上誤刪除

圖11:10.21.13.207上的誤刪除資料


2. 10.21.13.208上誤刪除資料獲取


圖12:10.21.13.208上的誤刪除資料的獲取


3. 10.21.13.207上恢復誤刪除資料並確認

圖13:10.21.13.207上的誤刪除資料的恢復


4.    10.21.13.208上恢復資料的確認

圖14:10.21.13.208上的誤刪除資料的驗證


結論:主庫上的DML誤操作後,1min內將誤操作的資料從備庫上可匯出。匯出的資料可在主庫上進行恢復。恢復後的資料保持一致。


3.5.3 Truncate 的驗證

10.21.13.207:

圖15:10.21.13.207上的truncate


10.21.13.208:

圖16:10.21.13.208上的查詢等待


結論:主庫上的truncate立即執行完成;備庫檢測到 truncate 時,會等待當前的 select,查詢等待時間為1min。


3.5.4 drop table 的驗證

10.21.13.207:

圖17:10.21.13.207上的drop


10.21.13.208:

圖18:10.21.13.208上的查詢等待


結論:主庫上的drop立即執行完成;備庫檢測到 drop 時,會等待當前的 select,查詢等待時間為1min。



04

探索總結


綜上所述,在 AntDB資料庫 的延遲複製的機制下,當業務對資料庫進行了誤刪除資料時,可以通過匯出 延遲備庫 的資料來對 主庫 資料進行修復。 AntDB資料庫能夠 實現業務的快速恢復 ,保障核心系統的穩定執行,從而有力支撐了業務的穩定性和連續性,提升了終端使用者的體驗。



關於我們


AntDB資料庫始於2008年,在運營商的核心繫統上,為全國24個省份的10億多使用者提供線上服務;廣泛應用於通訊、金融、交通、能源、物聯網等行業,在200多個專案上成功落地。AntDB資料庫具備高效能、彈性擴充套件、高可靠等產品特性,峰值每秒可處理百萬筆電信核心交易,並保障系統持續0故障執行近十年。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70000893/viewspace-2901671/,如需轉載,請註明出處,否則將追究法律責任。

相關文章