ApsaraDB for MongoDB：資料恢複概覽

執行個體資料可以恢複到的時間範圍，與備份資料的保留天數相關。如果您希望恢複更早之前的資料，請參見長期保留備份。

恢複資料到新執行個體的耗時取決於執行個體的儲存類型、備份資料量、需要回放的oplog資料量以及新執行個體規格，通常需要數分鐘到數小時不等。

一次完整的恢複包含以下三個階段，總耗時為三個階段之和：

影響恢複耗時的因素

• 儲存類型：雲端硬碟版執行個體的全量恢複基於快照掛載，速度顯著快於本地碟版執行個體的下載與解壓。

• 備份組大小：備份資料量越大，本地碟版執行個體的下載耗時越長；雲端硬碟版執行個體不受此影響。

• 資料檔案個數：集合數與索引數越多，本地碟版執行個體的解壓耗時越長。

• 新執行個體規格：新執行個體的CPU核心數、記憶體和磁碟IOPS越高，下載、解壓與oplog回放速度越快。使用低規格執行個體恢複巨量資料量執行個體時，耗時會明顯增加。

• oplog資料量：按時間點建立執行個體時，所選時間點距離全量備份時間點越遠，需要回放的oplog越多，耗時越長。

• oplog內容複雜度：oplog中的多文檔事務需串列回放，無法並行加速；大文檔、熱點更新會帶來額外的寫入放大。在複雜寫入負載下，即使提高執行個體規格，回放速度也可能無明顯改善。

• 源執行個體寫入速率：按時間點建立執行個體時，源執行個體寫入越快，同一時間視窗內產生的oplog越多，回放耗時越長。

• 分區叢集：分區叢集的ConfigServer、各分區與Mongos並行恢複，整體完成時間取決於耗時最長的組件，通常不短於同等資料量的複本集執行個體。

縮短恢複耗時的建議

• 優先選用雲端硬碟版執行個體，其全量恢複為分鐘級，且不受資料量與集合數量影響。

• 為新執行個體選擇不低於源執行個體的規格，避免在恢複階段出現規格瓶頸。

• 優先從備份點建立執行個體。如業務允許，選擇距離目標時間點最近的備份點，可減少甚至免除oplog回放耗時。

• 控制集合與索引數量，及時清理不再使用的集合和索引，可顯著降低本地碟版執行個體的解壓耗時。

• 開啟高頻備份，縮短備份點與目標時間點之間的間隔，從而減少需要回放的oplog資料量。

分區叢集雲端硬碟版執行個體可以使用庫表恢複功能將資料恢複至原執行個體。具體操作，請參見恢複ApsaraDB for MongoDB單個或多個資料庫。

若您的執行個體不支援通過庫表恢複功能恢複至原執行個體，可以先將備份資料恢複至新執行個體，然後依次修改原執行個體與新執行個體的串連地址和連接埠資訊，或者通過DTS將新執行個體的資料移轉至原執行個體。

• 修改執行個體的串連地址和連接埠，具體操作，請參見修改串連地址和連接埠。

• DTS遷移的具體操作，請參見源為自建MongoDB或ApsaraDB for MongoDB的遷移方案。

已下載的備份檔案，不支援直接恢複至雲資料庫執行個體。您可以先將資料恢複至自建資料庫，然後通過DTS遷移至ApsaraDB for MongoDB執行個體。DTS遷移的具體操作，請參見源為自建MongoDB或ApsaraDB for MongoDB的遷移方案。

• 您可以通過DTS將執行個體資料移轉至自建資料庫中。具體操作，請參見源為自建MongoDB或ApsaraDB for MongoDB的遷移方案。

• 使用MongoDB資料庫內建的備份還原工具Mongodump和Mongorestore，備份和恢複執行個體。

分區叢集執行個體的Config Server中儲存了所有分區集合的路由中繼資料（例如config.collections和config.chunks等集合）。這些集合的文檔中包含類似shard: 'shard01'的欄位，用於標識資料所屬的分區。複製恢複時需要使用源執行個體的完整路由資料，因此必須保留源執行個體的分區ID（即分區名稱），導致複製執行個體的分區ID與sh.status()輸出中顯示的分區名稱不一致。

您可以通過控制台分區叢集執行個體詳情頁中展示的分區標識ID（即replicaSetName），結合sh.status()的輸出結果來建立分區的映射關係。該映射關係在恢複完成後不會發生變化。