關鍵詞 ：同步複製；非同步複製；延遲複製；資料庫引數

01

資料庫容災概述

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

02

AntDB延遲複製的原理

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

複製的基本原理

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

圖1：AntDB同步複製原理

圖2：AntDB非同步複製原理

延遲複製的基本原理

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

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

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

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

圖3：AntDB延遲複製的原理

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

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

延遲複製災備方案的示例

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

環境資訊

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

搭建主備複製

1.10.21.13.207構建主庫：

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故障執行近十年。