1、數據庫誤刪表恢復方案

應用數據的完整性是保證應用系統正常服務的重要基礎，在實際應用DDL部署過程或數據庫變更過程中，可能因為誤操作導致應用關鍵表被誤刪除或truncate，影響業務的正常訪問。分布式數據庫中當誤刪表時有不同的數據恢復方案：

• 基于數據庫備份+增量日志：該方案的前提是數據庫有一份全量的備份數據，在這個全量備份數據的基礎之上應用增量的數據庫日志，并且跳過誤操作的日志，進而完成表數據的恢復。基于數據庫備份的恢復方案在庫數據量大或者增量日志多的時候耗時較長，在這個恢復的過程中應用是無法正常訪問的。
• 基于閃回技術：數據庫閃回技術是基于回收站和數據庫undo日志完成數據庫的恢復操作，undo數據用于記錄數據修改之前的狀態信息，數據庫會將這部分數據寫入undo段中用于回滾事務，或者發生錯誤時恢復數據到修改前的狀態。對于誤刪表等操作，數據庫中實際上是一個rename操作，將表移動到回收站，只要回收站中的空間足夠且未被清理，就可以使用閃回刪除來恢復被刪除的表。
• 基于延遲復制方案：延遲復制一般是在主備部署架構的數據庫中通過備節點延遲復制主節點的數據，當主節點出現邏輯上的誤操作如誤刪表時，利用備節點延遲同步和跳過特定的誤操作事務日志來恢復數據。延遲復制通常是在生產集群之外再建一個單獨的最小化備集群，需要額外的部署成本，同時依賴數據庫廠商實現延遲復制并跳過特定的事務。

在誤刪表的故障場景下業務訪問誤刪除的表會報錯，業務對其它表的訪問仍然正常。下文將簡要介紹分布式數據庫下以上三種誤刪表操作下的數據恢復方法。

2、分布式數據庫下誤刪表恢復方法

2.1 基于備份+增量日志的恢復

數據庫的完整備份數據和增量日志是保證數據庫完整性的基礎，一些重要的應用系統每天會進行全量或增量的數據庫備份，在數據恢復的過程中首先基于這些備份數據恢復到備份時點的數據，再通過增量日志追加的方式將數據恢復到PITR一致時間點。在誤刪表等特殊場景下，增量追加日志的時候需要將這一特殊的操作跳過，而在分布式數據庫中還需要恢復多個實例的數據和以及計算節點層的元數據信息。以下以GoldenDB分布式數據庫為例介紹這種誤刪表恢復方案的恢復過程。

圖片

1）恢復誤刪表的表結構從保存的DDL中恢復出表結構信息，用于后續表結構恢復。

2）登錄到每個分片的主節點，解析binlog并獲取到刪表操作的gtidX信息

#執行命令
$mysqlbinlog -vv mysql-bin.xxx |grep -i -B20 ‘drop table’

找到類似如下信息：

SET @@SESSION.GTID_NEXT=’xxxx’/*!*/;
DROP TABLE xx.xx /*generated by server*/

3）選取待恢復的備節點，并使用全量備份數據恢復備節點

##停止備節點
$dbmoni -stop
##使用restore命令恢復備節點
$restory.py --full_backup_filename=xx --my_cnf=xx.cnf --db_user=xx --db_password=xx

4）追binlog到當前狀態，并跳過刪表的gtid檢查備節點狀態，dbagent非啟動，并且數據庫實例是啟動的

$dbstate

設置gtid_next并手動執行空事務，跳過drop table對應的操作，gtid_next為之前解析binlog找到的

> set @@session_gtid_next=’xxxx’;
> begin;
> commit;

啟動dbagent，將備機接入集群，開啟自動主從復制

##啟動備節點
$dbmoni -start

5）檢查主備同步的狀態，確認備機已追上主機

$show slave status \G
$show tables like ‘xx’

此時備機中之前誤刪除的表數據已經恢復。

6）發起主備切換，將恢復的備機作為主節點對外提供服務此時雖然主備切換成功，備節點作為新主，但是原主節點作為備機，和新主節點之間數據是不一致的，需要通過修復備機的方式恢復。

7）登錄Proxy節點，更新元數據信息。此時雖然數據節點已經恢復了表數據，但是在計算節點層沒有該表的元數據信息，需要通過恢復的元數據信息更新計算層的元數據。

8）修復其它備機狀態新發起全量備份，通過備份數據恢復其它備機。注意在主節點發起備份時候對性能會有部分損耗，比如響應時間增加、IO影響等。

基于全量備份+增量日志的誤刪表恢復方法，在表數據恢復期間業務訪問這部分表會報錯，整個故障的RTO時間依賴于全量備份的恢復加上增量日志追平。在單主節點對外提供服務的時候，需要調整相關的配置，比如調整高低水位和主計數等，優先可用性。

2.2 基于閃回空間的恢復

基于閃回空間的恢復是利用了回收站的機制，當用戶執行DROP表操作時，數據庫并不會立即從磁盤上刪除表的物理文件，而是將其移動到回收站中。回收站中的對象可以被視為被“軟刪除”，即它們仍然存在于數據庫中，但不再對用戶可見。多個分布式數據庫已支持閃回功能，比如TiDB、GaussDB、OceanBase、GoldenDB等。以GaussDB數據庫為例，回收站功能通過數據庫參數enable_recyclebin來啟用或禁用。回收站中對象的保留時間由參數recyclebin_retention_time來控制，超過該時間的對象將被自動清理。利用閃回恢復只需要秒級，并且恢復時間和數據庫大小無關。

#閃回被刪除的表
TIMECAPSULE TABLE { table_name } TO BEFORE DROP [RENAME TO new_tablename]
#閃回截斷的表
TIMECAPSULE TABLE { table_name } TO BEFORE TRUNCATE

1）查看回收站，刪除的表被放入回收站

gaussdb=# SELECT * FROM gs_recyclebin;
 rcybaseid | rcydbid | rcyrelid |           rcyname            |    rcyoriginname     | rcyoperation | rcytype | rcyrecyclecsn |        rcyrecycletime         | rcycreatecsn | rcychangecs
n | rcynamespace | rcyowner | rcytablespace | rcyrelfilenode | rcycanrestore | rcycanpurge | rcyfrozenxid | rcyfrozenxid64 | rcybucket 
-----------+---------+----------+------------------------------+----------------------+--------------+---------+---------------+-------------------------------+--------------+------------
--+--------------+----------+---------------+----------------+---------------+-------------+--------------+----------------+-----------
     18591 |   12737 |    18585 | BIN$42C23EB5699$9737$0==$0   | test            | d            |       0 |      79352606 | 2024-09-13 20:01:28.640664+08 |     79352595 |     7935259
5 |         2200 |       10 |             0 |          18585 | t             | t           | 225492       |         225492 |

2）閃回drop表

gaussdb=# TIMECAPSULE TABLE test to before drop;

查看表數據已經恢復

閃回功能是一種強大的數據恢復技術，在使用上受到閃回時間點和舊版本保留時間的限制。

• 閃回時間點限制：閃回功能只能回滾到開啟閃回功能后的某個時間點，且只能回滾到最近的一個事務提交點。這意味著，如果數據庫在開啟閃回功能之前已經發生了錯誤操作，那么這些操作將無法通過閃回功能來恢復。
• 舊版本保留時間：閃回功能依賴于舊版本的保留時間。如果舊版本數據被清理或刪除，那么將無法回滾到這些時間點。因此，用戶需要合理配置舊版本保留時間，以確保能夠回滾到所需的時間點。

另外閃回功能只支持部分DDL操作，比如drop表、truncate表等，對于誤刪庫、drop某個字段，以及因為硬件故障導致的數據不一致是無法恢復的。

2.3 基于延遲復制的恢復

基于延遲復制的誤刪表數據恢復方案在“國產分布式數據庫災備高可用實現”一文中做過介紹，如OceanBase數據庫的物理備庫方案、GoldenDB數據庫的DRSP災備集群方案。實現上主要是依賴分布式數據庫的災備架構建立一套延遲備庫集群，主備集群之間通過設置合理的延遲時間，當主集群出現誤操作時，通過在備集群跳過對應操作的事務，完成主庫的數據同步，再切換到備集群對外提供服務。從實現機制上看和基于備份和增量日志的方式原理類似，少了全量備份數據恢復的動作，減少了恢復的RTO時間。相對應的是部署建設成本的增加，需要在生產站點單獨再部署一套備庫集群用于故障場景下的數據恢復，成本和收益的權衡，畢竟有更多的措施來預防這一類的故障場景。

2.4 不同恢復方案對比

總結以上三種針對誤刪表場景下的不同的數據恢復方案，在恢復RTO時間、技術復雜度、部署成本和使用限制等方面進行了對比如下：

• 恢復RTO

a.全量備份+增量日志：先基于全量備份恢復表，再加上增量日志追加方式，數據恢復時間長

b.閃回空間：支持秒級恢復

c.延遲復制：基于日志同步回放，時間較長

• 部署復雜度

a.全量備份+增量日志：PITR恢復是數據庫的基本功能，方案成熟但操作復雜，需要找到drop操作的gtid、指定備機跳過gtid先恢復備機

b.閃回空間：操作簡單，依賴于數據庫本身的功能實現

c.延遲復制：不成熟并且操作復雜，依賴于數據庫的高可用架構實現

• 部署成本

a.全量備份+增量日志：低，基于現有的部署架構，不會增加額外的成本

b.閃回空間：一般，增加額外的存儲空間，并且開啟閃回功能會影響一定性能

c.延遲復制：高，需要額外部署一套備集群

• 技術限制

a.全量備份+增量日志：無

b.閃回空間：邏輯上恢復，只支持部分DDL操作；保留時間上也存在限制

c.延遲復制：延遲時間設置上有限制，超過時間后已經同步到備機

在實際應用過程中，如果數據庫本身支持閃回功能優先使用該恢復方案，能夠滿足快速的RTO恢復要求。在閃回功能不成熟或沒有該功能時，選擇全量備份的恢復方式，方案成熟并且通用性強。

參考資料

1. GoldenDB分布式數據庫備份恢復
2. GaussDB數據庫閃回恢復
3. 國產分布式數據庫延遲復制實現