當發生部分表的誤操作時，可進行庫表恢複，將誤操作的某張表或某些表恢複到原叢集。
庫表恢複分為按時間點恢複和按備份組（快照）恢複，兩者的區別在於要恢複至的時間點是否是備份組的時間點。如果是備份組的時間點，則可選擇按備份組（快照）恢複更方便。如果要恢複至的時間不是已有的備份組的時間點，則只能選擇按時間點恢複。
庫表恢複新流程已在PolarDB MySQL版8.0.1版本且小版本為8.0.1.1.49及以上版本灰階發布Fast Import新特性。
整體流程
無論是按時間點恢複還是按備份組（快照）恢複，兩者的關鍵流程是一致的：先建立一個臨時節點，並將某個時間點的資料恢複至該節點，然後再將恢複出的資料恢複到原叢集。
庫表恢複新版已於2024年04月03日發布，相比舊版，最佳化了向原叢集恢複資料的時間，並且熱備叢集以及GDN從叢集可自動同步資料，大幅減少了任務的恢復。
適用範圍
庫表恢複功能支援PolarDB企業版和標準版，但對叢集的修訂版本有特定要求。不同情境下的最低版本要求如下表所示。
基礎功能：代表支援庫表恢複所需滿足的最低版本。
新版恢複流程：代表獲得新版恢複流程速度最佳化時，所需滿足的更高版本要求。
版本系列 | MySQL 版本 | 架構 | 基礎功能（最低修訂版本） | 新版恢複流程（最低修訂版本） |
企業版（叢集版） | 5.6 | X86 |
|
|
5.7 | X86 |
|
| |
8.0.1 | X86 |
|
| |
8.0.2 | X86 |
|
| |
標準版 | 5.6 | X86 |
|
|
5.7 | X86 |
|
| |
8.0.1 | X86 |
|
| |
倚天（ARM） |
|
| ||
8.0.2 | X86 |
|
|
您可在PolarDB MySQL版叢集的基本資料頁面的配置資訊地區查看當前叢集的核心版本。
新舊版本流程圖
當叢集的修訂版本符合上述版本要求時，將自動進入庫表恢複新版恢複流程。舊版和新版流程原理圖如下：
建議在業務低峰期進行資料恢複。
預估時間
各步驟預估耗時
步驟 | 預估耗時 |
建立一個臨時節點，並將備份組中的資料恢複至該節點。 | 約3~10分鐘。 |
恢複Redo日誌增量資料。 說明 僅按時間點恢複的方式需要恢複該類資料。耗時和需要應用的Redo日誌大小相關。 | 1.5 GB/分鐘。 |
將資料恢複至原叢集。 | 預估耗時請參見庫表恢複速度測試資料參考。 |
以上資料僅供參考。
如果待恢複的資料量達到TB層級，執行庫表恢複操作可能耗時較長。如果想要快速恢複該資料，可使用備份組全量恢複，一般耗時幾分鐘。具體操作請參見全量恢複方式1：從備份組恢複。
庫表恢複速度測試資料參考
CPU和記憶體（獨享） | 測試資料 | innodb_io_capacity | innodb_io_capacity_max | 舊版流程 | 新版流程 | 新版較舊版恢複速度對比 | |||||
是否開啟儲存熱備 | 恢複耗時 | 恢複速度 | 恢複速度配置 | 恢複耗時 | 恢複速度 | （舊版流程）是否開啟儲存熱備 | 速度提升 | ||||
2核8 GB | 單表200 GB左右 | 4000 | 8000 | 是 | 3小時38分鐘25秒 | 1.03 GB/分鐘 | 常規 | 1小時43分鐘36秒 | 2.16 GB/分鐘 | 是 | 110% |
否 | 2小時23分鐘0秒 | 1.57 GB/分鐘 | 否 | 38% | |||||||
4核16 GB | 單表200 GB左右 | 4000 | 8000 | 是 | 3小時3分鐘31秒 | 1.14 GB/分鐘 | 快速 | 54分13秒 | 3.70GB/分鐘 | 是 | 225% |
否 | 88% | ||||||||||
常規 | 1小時20分 | 2.5GB/分鐘 | 是 | 119% | |||||||
否 | 1小時45分鐘53秒 | 1.97 GB/分鐘 | 否 | 27% | |||||||
安全 | 2小時12分 | 1.52GB/分鐘 | 是 | 33% | |||||||
否 | -30% | ||||||||||
8000 | 16000 | 是 | 3小時3分鐘15秒 | 1.14 GB/分鐘 | 快速 | 42分18秒 | 4.76GB/分鐘 | 是 | 318% | ||
否 | 142% | ||||||||||
常規 | 54分16秒 | 3.70GB/分鐘 | 是 | 225% | |||||||
否 | 1小時45分鐘53秒 | 1.97 GB/分鐘 | 否 | 88% | |||||||
安全 | 1小時20分 | 2.5GB/分鐘 | 是 | 119% | |||||||
否 | 27% | ||||||||||
8核32 GB | 單表200 GB左右 | 4000 | 8000 | 是 | 2小時50分鐘56秒 | 1.19 GB/分鐘 | 快速 | 54分39秒 | 3.70GB/分鐘 | 是 | 211% |
否 | 80% | ||||||||||
常規 | 1小時21分 | 2.47GB/分鐘 | 是 | 108% | |||||||
否 | 1小時38分鐘57秒 | 2.05 GB/分鐘 | 否 | 20% | |||||||
安全 | 2小時12分 | 1.52GB/分鐘 | 是 | 28% | |||||||
否 | -35% | ||||||||||
18000 | 36000 | 是 | 2小時51分鐘5秒 | 1.19 GB/分鐘 | 快速 | 41分48秒 | 4.88GB/分鐘 | 是 | 310% | ||
否 | 273% | ||||||||||
常規 | 54分43秒 | 3.70GB/分鐘 | 是 | 211% | |||||||
否 | 1小時38分鐘33秒 | 1.31 GB/分鐘 | 否 | 182% | |||||||
安全 | 1小時21分 | 2.47GB/分鐘 | 是 | 108% | |||||||
否 | 89% | ||||||||||
16核64 GB | 單表200 GB左右 | 4000 | 8000 | 是 | 2小時55分鐘26秒 | 1.17 GB/分鐘 | 快速 | 53分28秒 | 3.77GB/分鐘 | 是 | 222% |
否 | 88% | ||||||||||
常規 | 1小時20分 | 2.5GB/分鐘 | 是 | 114% | |||||||
否 | 1小時42分鐘20秒 | 2.01 GB/分鐘 | 否 | 24% | |||||||
安全 | 2小時12分 | 1.52GB/分鐘 | 是 | 30% | |||||||
否 | -32% | ||||||||||
20000 | 40000 | 是 | 2小時53分鐘49秒 | 1.19 GB/分鐘 | 快速 | 41分1秒 | 4.88GB/分鐘 | 是 | 310% | ||
否 | 138% | ||||||||||
常規 | 54分5秒 | 3.70GB/分鐘 | 是 | 211% | |||||||
否 | 1小時40分鐘35秒 | 2.05 GB/分鐘 | 否 | 80% | |||||||
安全 | 1小時20分 | 2.5GB/分鐘 | 是 | 110% | |||||||
否 | 22% | ||||||||||
恢複速度是指將資料恢複到原叢集的速度，不包括恢複流程中建立臨時節點和恢複增量日誌步驟中所消耗的時間。
恢複速度與叢集是否開啟儲存熱備、叢集主節點規格、
innodb_io_capacity參數值大小、恢複速度配置以及待恢複的表數量有關。您可通過動態調整
innodb_io_capacity和innodb_io_capacity_max的值來調節恢複速度。參數值調整後，對庫表恢複舊版流程恢複速度影響較小，對新版流程的恢複速度影響較大。恢複速度根據所佔用的IOPS分為快速、常規和安全三種配置。所佔用的IOPS越多，實際恢複速度越快，尤其在大表恢複情境中，速度提升尤為明顯。
恢複速度配置對庫表恢複舊版流程恢複速度影響較小，對新版流程的恢複速度影響較大。
由於2核8 GB的規格較小，IO波動較大，恢複速度配置可能並不具有明顯的效果，因此未列出恢複速度的測試結果。
以上測試資料未包含表數量很多的情況，如果您指定恢複的表數量較多，也將會對恢複速度產生影響。
以上測試資料僅供參考，實際恢複速度受底層機器機型、網路等因素影響。