1、數(shù)據(jù)庫(kù)誤刪表恢復(fù)方案

應(yīng)用數(shù)據(jù)的完整性是保證應(yīng)用系統(tǒng)正常服務(wù)的重要基礎(chǔ)，在實(shí)際應(yīng)用DDL部署過(guò)程或數(shù)據(jù)庫(kù)變更過(guò)程中，可能因?yàn)檎`操作導(dǎo)致應(yīng)用關(guān)鍵表被誤刪除或truncate，影響業(yè)務(wù)的正常訪問(wèn)。分布式數(shù)據(jù)庫(kù)中當(dāng)誤刪表時(shí)有不同的數(shù)據(jù)恢復(fù)方案：

• 基于數(shù)據(jù)庫(kù)備份+增量日志：該方案的前提是數(shù)據(jù)庫(kù)有一份全量的備份數(shù)據(jù)，在這個(gè)全量備份數(shù)據(jù)的基礎(chǔ)之上應(yīng)用增量的數(shù)據(jù)庫(kù)日志，并且跳過(guò)誤操作的日志，進(jìn)而完成表數(shù)據(jù)的恢復(fù)。基于數(shù)據(jù)庫(kù)備份的恢復(fù)方案在庫(kù)數(shù)據(jù)量大或者增量日志多的時(shí)候耗時(shí)較長(zhǎng)，在這個(gè)恢復(fù)的過(guò)程中應(yīng)用是無(wú)法正常訪問(wèn)的。
• 基于閃回技術(shù)：數(shù)據(jù)庫(kù)閃回技術(shù)是基于回收站和數(shù)據(jù)庫(kù)undo日志完成數(shù)據(jù)庫(kù)的恢復(fù)操作，undo數(shù)據(jù)用于記錄數(shù)據(jù)修改之前的狀態(tài)信息，數(shù)據(jù)庫(kù)會(huì)將這部分?jǐn)?shù)據(jù)寫(xiě)入undo段中用于回滾事務(wù)，或者發(fā)生錯(cuò)誤時(shí)恢復(fù)數(shù)據(jù)到修改前的狀態(tài)。對(duì)于誤刪表等操作，數(shù)據(jù)庫(kù)中實(shí)際上是一個(gè)rename操作，將表移動(dòng)到回收站，只要回收站中的空間足夠且未被清理，就可以使用閃回刪除來(lái)恢復(fù)被刪除的表。
• 基于延遲復(fù)制方案：延遲復(fù)制一般是在主備部署架構(gòu)的數(shù)據(jù)庫(kù)中通過(guò)備節(jié)點(diǎn)延遲復(fù)制主節(jié)點(diǎn)的數(shù)據(jù)，當(dāng)主節(jié)點(diǎn)出現(xiàn)邏輯上的誤操作如誤刪表時(shí)，利用備節(jié)點(diǎn)延遲同步和跳過(guò)特定的誤操作事務(wù)日志來(lái)恢復(fù)數(shù)據(jù)。延遲復(fù)制通常是在生產(chǎn)集群之外再建一個(gè)單獨(dú)的最小化備集群，需要額外的部署成本，同時(shí)依賴(lài)數(shù)據(jù)庫(kù)廠商實(shí)現(xiàn)延遲復(fù)制并跳過(guò)特定的事務(wù)。

在誤刪表的故障場(chǎng)景下業(yè)務(wù)訪問(wèn)誤刪除的表會(huì)報(bào)錯(cuò)，業(yè)務(wù)對(duì)其它表的訪問(wèn)仍然正常。下文將簡(jiǎn)要介紹分布式數(shù)據(jù)庫(kù)下以上三種誤刪表操作下的數(shù)據(jù)恢復(fù)方法。

2、分布式數(shù)據(jù)庫(kù)下誤刪表恢復(fù)方法

2.1 基于備份+增量日志的恢復(fù)

數(shù)據(jù)庫(kù)的完整備份數(shù)據(jù)和增量日志是保證數(shù)據(jù)庫(kù)完整性的基礎(chǔ)，一些重要的應(yīng)用系統(tǒng)每天會(huì)進(jìn)行全量或增量的數(shù)據(jù)庫(kù)備份，在數(shù)據(jù)恢復(fù)的過(guò)程中首先基于這些備份數(shù)據(jù)恢復(fù)到備份時(shí)點(diǎn)的數(shù)據(jù)，再通過(guò)增量日志追加的方式將數(shù)據(jù)恢復(fù)到PITR一致時(shí)間點(diǎn)。在誤刪表等特殊場(chǎng)景下，增量追加日志的時(shí)候需要將這一特殊的操作跳過(guò)，而在分布式數(shù)據(jù)庫(kù)中還需要恢復(fù)多個(gè)實(shí)例的數(shù)據(jù)和以及計(jì)算節(jié)點(diǎn)層的元數(shù)據(jù)信息。以下以GoldenDB分布式數(shù)據(jù)庫(kù)為例介紹這種誤刪表恢復(fù)方案的恢復(fù)過(guò)程。

圖片

1）恢復(fù)誤刪表的表結(jié)構(gòu)從保存的DDL中恢復(fù)出表結(jié)構(gòu)信息，用于后續(xù)表結(jié)構(gòu)恢復(fù)。

2）登錄到每個(gè)分片的主節(jié)點(diǎn)，解析binlog并獲取到刪表操作的gtidX信息

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

找到類(lèi)似如下信息：

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

3）選取待恢復(fù)的備節(jié)點(diǎn)，并使用全量備份數(shù)據(jù)恢復(fù)備節(jié)點(diǎn)

##停止備節(jié)點(diǎn)
$dbmoni -stop
##使用restore命令恢復(fù)備節(jié)點(diǎn)
$restory.py --full_backup_filename=xx --my_cnf=xx.cnf --db_user=xx --db_password=xx

4）追binlog到當(dāng)前狀態(tài)，并跳過(guò)刪表的gtid檢查備節(jié)點(diǎn)狀態(tài)，dbagent非啟動(dòng)，并且數(shù)據(jù)庫(kù)實(shí)例是啟動(dòng)的

$dbstate

設(shè)置gtid_next并手動(dòng)執(zhí)行空事務(wù)，跳過(guò)drop table對(duì)應(yīng)的操作，gtid_next為之前解析binlog找到的

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

啟動(dòng)dbagent，將備機(jī)接入集群，開(kāi)啟自動(dòng)主從復(fù)制

##啟動(dòng)備節(jié)點(diǎn)
$dbmoni -start

5）檢查主備同步的狀態(tài)，確認(rèn)備機(jī)已追上主機(jī)

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

此時(shí)備機(jī)中之前誤刪除的表數(shù)據(jù)已經(jīng)恢復(fù)。

6）發(fā)起主備切換，將恢復(fù)的備機(jī)作為主節(jié)點(diǎn)對(duì)外提供服務(wù)此時(shí)雖然主備切換成功，備節(jié)點(diǎn)作為新主，但是原主節(jié)點(diǎn)作為備機(jī)，和新主節(jié)點(diǎn)之間數(shù)據(jù)是不一致的，需要通過(guò)修復(fù)備機(jī)的方式恢復(fù)。

7）登錄Proxy節(jié)點(diǎn)，更新元數(shù)據(jù)信息。此時(shí)雖然數(shù)據(jù)節(jié)點(diǎn)已經(jīng)恢復(fù)了表數(shù)據(jù)，但是在計(jì)算節(jié)點(diǎn)層沒(méi)有該表的元數(shù)據(jù)信息，需要通過(guò)恢復(fù)的元數(shù)據(jù)信息更新計(jì)算層的元數(shù)據(jù)。

8）修復(fù)其它備機(jī)狀態(tài)新發(fā)起全量備份，通過(guò)備份數(shù)據(jù)恢復(fù)其它備機(jī)。注意在主節(jié)點(diǎn)發(fā)起備份時(shí)候?qū)π阅軙?huì)有部分損耗，比如響應(yīng)時(shí)間增加、IO影響等。

基于全量備份+增量日志的誤刪表恢復(fù)方法，在表數(shù)據(jù)恢復(fù)期間業(yè)務(wù)訪問(wèn)這部分表會(huì)報(bào)錯(cuò)，整個(gè)故障的RTO時(shí)間依賴(lài)于全量備份的恢復(fù)加上增量日志追平。在單主節(jié)點(diǎn)對(duì)外提供服務(wù)的時(shí)候，需要調(diào)整相關(guān)的配置，比如調(diào)整高低水位和主計(jì)數(shù)等，優(yōu)先可用性。

2.2 基于閃回空間的恢復(fù)

基于閃回空間的恢復(fù)是利用了回收站的機(jī)制，當(dāng)用戶(hù)執(zhí)行DROP表操作時(shí)，數(shù)據(jù)庫(kù)并不會(huì)立即從磁盤(pán)上刪除表的物理文件，而是將其移動(dòng)到回收站中。回收站中的對(duì)象可以被視為被“軟刪除”，即它們?nèi)匀淮嬖谟跀?shù)據(jù)庫(kù)中，但不再對(duì)用戶(hù)可見(jiàn)。多個(gè)分布式數(shù)據(jù)庫(kù)已支持閃回功能，比如TiDB、GaussDB、OceanBase、GoldenDB等。以GaussDB數(shù)據(jù)庫(kù)為例，回收站功能通過(guò)數(shù)據(jù)庫(kù)參數(shù)enable_recyclebin來(lái)啟用或禁用。回收站中對(duì)象的保留時(shí)間由參數(shù)recyclebin_retention_time來(lái)控制，超過(guò)該時(shí)間的對(duì)象將被自動(dòng)清理。利用閃回恢復(fù)只需要秒級(jí)，并且恢復(fù)時(shí)間和數(shù)據(jù)庫(kù)大小無(wú)關(guān)。

#閃回被刪除的表
TIMECAPSULE TABLE { table_name } TO BEFORE DROP [RENAME TO new_tablename]
#閃回截?cái)嗟谋?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;

查看表數(shù)據(jù)已經(jīng)恢復(fù)

閃回功能是一種強(qiáng)大的數(shù)據(jù)恢復(fù)技術(shù)，在使用上受到閃回時(shí)間點(diǎn)和舊版本保留時(shí)間的限制。

• 閃回時(shí)間點(diǎn)限制：閃回功能只能回滾到開(kāi)啟閃回功能后的某個(gè)時(shí)間點(diǎn)，且只能回滾到最近的一個(gè)事務(wù)提交點(diǎn)。這意味著，如果數(shù)據(jù)庫(kù)在開(kāi)啟閃回功能之前已經(jīng)發(fā)生了錯(cuò)誤操作，那么這些操作將無(wú)法通過(guò)閃回功能來(lái)恢復(fù)。
• 舊版本保留時(shí)間：閃回功能依賴(lài)于舊版本的保留時(shí)間。如果舊版本數(shù)據(jù)被清理或刪除，那么將無(wú)法回滾到這些時(shí)間點(diǎn)。因此，用戶(hù)需要合理配置舊版本保留時(shí)間，以確保能夠回滾到所需的時(shí)間點(diǎn)。

另外閃回功能只支持部分DDL操作，比如drop表、truncate表等，對(duì)于誤刪庫(kù)、drop某個(gè)字段，以及因?yàn)橛布收蠈?dǎo)致的數(shù)據(jù)不一致是無(wú)法恢復(fù)的。

2.3 基于延遲復(fù)制的恢復(fù)

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

2.4 不同恢復(fù)方案對(duì)比

總結(jié)以上三種針對(duì)誤刪表場(chǎng)景下的不同的數(shù)據(jù)恢復(fù)方案，在恢復(fù)RTO時(shí)間、技術(shù)復(fù)雜度、部署成本和使用限制等方面進(jìn)行了對(duì)比如下：

• 恢復(fù)RTO

a.全量備份+增量日志：先基于全量備份恢復(fù)表，再加上增量日志追加方式，數(shù)據(jù)恢復(fù)時(shí)間長(zhǎng)

b.閃回空間：支持秒級(jí)恢復(fù)

c.延遲復(fù)制：基于日志同步回放，時(shí)間較長(zhǎng)

• 部署復(fù)雜度

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

b.閃回空間：操作簡(jiǎn)單，依賴(lài)于數(shù)據(jù)庫(kù)本身的功能實(shí)現(xiàn)

c.延遲復(fù)制：不成熟并且操作復(fù)雜，依賴(lài)于數(shù)據(jù)庫(kù)的高可用架構(gòu)實(shí)現(xiàn)

• 部署成本

a.全量備份+增量日志：低，基于現(xiàn)有的部署架構(gòu)，不會(huì)增加額外的成本

b.閃回空間：一般，增加額外的存儲(chǔ)空間，并且開(kāi)啟閃回功能會(huì)影響一定性能

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

• 技術(shù)限制

a.全量備份+增量日志：無(wú)

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

c.延遲復(fù)制：延遲時(shí)間設(shè)置上有限制，超過(guò)時(shí)間后已經(jīng)同步到備機(jī)

在實(shí)際應(yīng)用過(guò)程中，如果數(shù)據(jù)庫(kù)本身支持閃回功能優(yōu)先使用該恢復(fù)方案，能夠滿(mǎn)足快速的RTO恢復(fù)要求。在閃回功能不成熟或沒(méi)有該功能時(shí)，選擇全量備份的恢復(fù)方式，方案成熟并且通用性強(qiáng)。

參考資料

1. GoldenDB分布式數(shù)據(jù)庫(kù)備份恢復(fù)
2. GaussDB數(shù)據(jù)庫(kù)閃回恢復(fù)
3. 國(guó)產(chǎn)分布式數(shù)據(jù)庫(kù)延遲復(fù)制實(shí)現(xiàn)