恢複MySQL全量資料 - ApsaraDB RDS

如果您擁有原執行個體的資料備份和記錄備份，可以將其恢複到新執行個體中，可用於誤操作後恢複以及分析歷史資料等情境。

前提條件

原執行個體需要滿足如下條件：

執行個體運行狀態為運行中且沒有被鎖定。
當前沒有進行中的遷移任務。
已完成備份。RDS預設有自動備份。更多備份方式，請參見備份方案概覽。
按時間點恢複時，需要確保記錄備份已開啟。如何開啟，請參見RDS MySQL記錄備份。
按備份組恢複時，原執行個體必須至少有一個物理備份。更多資訊，請參見自動備份。

功能說明

類別	說明
恢複範圍	恢複整個執行個體。
新執行個體各配置項	新執行個體的白名單設定、備份設定、參數設定和當前執行個體保持一致。
新執行個體帳號資訊	新執行個體內含恢複時所選擇的備份時間點或備份組當時的帳號資訊。
新執行個體資料	新執行個體內的資料與用於恢複的備份檔案中的資料一致。
恢複的時間點	未開啟記錄備份時，只能恢複至已有的資料備份所在的時間點。開啟常規記錄備份後，可以恢複到記錄備份保留天數內的任意時間點。開啟任意時間點恢複（記錄備份升級版）後，在可任意時間點恢複天數內，恢複任意時間點的資料。說明如何查看當前記錄備份保留天數策略，請參見RDS MySQL記錄備份。更多詳情，請參見任意時間點保護與記錄備份的區別。
恢複時間長度	恢複時間長度受多種因素影響。200 GB的資料大約需要3小時恢複。詳情請參見本文常見問題。

費用說明

由於資料是恢複到新執行個體上，因此需要收取新執行個體費用，費用詳情可在建立執行個體時查看。

說明

如臨時使用，您可以建立隨用隨付或Serverless的新執行個體，把資料遷移到原執行個體，然後釋放新執行個體。
執行個體建立完成後開始計費。

功能開啟

恢複全量資料功能無需手動開啟。新執行個體建立成功後會自動進行周期性備份，您可使用備份完成的資料備份和記錄備份進行全量資料恢複。

操作步驟

使用原執行個體的備份資料建立新執行個體進行資料恢複，不影響原執行個體效能。

訪問RDS執行個體列表，在上方選擇地區，然後單擊目標執行個體ID。
在左側導覽列單擊備份恢複。
在備份恢複頁面左上方，單擊資料庫恢複。
說明
您也可以單擊基本資料頁面執行個體分布地區的資料庫恢複按鈕。

在資料庫恢複頁面，選擇待恢複的時間點或備份組，並對新執行個體進行基礎資源配置。

類別	說明
計費方式	訂用帳戶：預付費，適合長期需求，時間長度越長折扣越多。隨用隨付：後付費（按小時計費），適合短期需求，用完可釋放。
還原方式	按備份組：恢複指定備份組資料（暫不支援邏輯備份）。按時間點：需開啟記錄備份，可恢複保留期內任意時間點資料。
產品類型	源執行個體為基礎系列：無此參數。源執行個體為高可用系列：儲存類型為ESSD雲端硬碟或高效能雲端硬碟，可選擇標準版或倚天版，詳情請參見產品類型。儲存類型為高效能本地碟，僅支援標準版。源執行個體為叢集系列，可選擇標準版或倚天版。
可用性區域	您可以設定執行個體為單可用性區域部署或多可用性區域部署：單可用性區域部署：主備節點同區。多可用性區域部署（推薦）：主備節點跨區部署，支援容災。說明執行個體建立後，您可以在執行個體的服務可用性頁面查看主備節點資訊。基礎系列執行個體僅支援單可用性區域。
執行個體規格	通用規格：獨享記憶體和I/O資源，與同一伺服器上的其他通用型執行個體共用CPU和儲存資源。獨享規格：獨享型指獨享被分配的CPU、記憶體、儲存和I/O資源。獨佔型是獨享型的頂配，獨佔整台伺服器的CPU、記憶體、儲存和I/O資源。說明每種規格都有對應的CPU核心數、記憶體、最大串連數和最大IOPS。詳情請參見主執行個體規格列表。
儲存空間	包括資料、系統檔案、Binlog檔案和事務檔案空間。調整步長為5 GB。

單擊下一步：執行個體配置，配置執行個體網路類型和資源群組，設定如下參數。

類別	說明
網路類型	傳統網路：傳統的網路類型。專用網路（推薦）：也稱為VPC（Virtual Private Cloud）。VPC是一種隔離的網路環境，安全性和效能均高於傳統的傳統網路。選擇專用網路時您需要選擇對應的VPC和主節點交換器，如果您在上一步的基礎資源中配置了多可用性區域部署，則還需要選擇備選節點交換器。說明請確保RDS執行個體與需要串連的ECS執行個體網路類型一致（如果選擇專用網路，還需要保證VPC一致），否則它們無法通過內網互連。
資源群組	資源群組是在阿里雲帳號下進行資源分組管理的一種機制，能夠協助您解決單個雲帳號內的資源分組和授權管理的複雜性問題。您可以選擇已有資源群組或建立新資源群組。如無資源分組管理需求，可選擇預設資源群組。

單擊下一步：確認訂單。
確認參數配置，選擇購買量和購買時間長度（僅訂用帳戶執行個體），勾選服務合約，單擊確認下單完成支付。
說明
對於訂用帳戶執行個體，建議勾選到期自動續約，可以免去您定期手動續約的煩惱，且不會因忘記續約而導致業務中斷。
（可選）後續如需登入到新執行個體並驗證資料。關於登入執行個體的操作，請參見串連執行個體。

訂正線上資料

恢複到新執行個體後，您可使用資料轉送DTS將需要的部分或全部庫表資料遷移至原執行個體以訂正原執行個體線上資料。

說明

建立資料移轉任務時，請將已恢複的新執行個體作為源庫，將原執行個體作為目標庫，接入方式均選擇雲執行個體。

常見問題

誤刪除了一個或多個庫，如何恢複？

您可以進行庫表恢複。對於不支援庫表恢複的執行個體，您可以參見本文，將資料全量恢複到新執行個體上，經過驗證後，再將資料遷回原執行個體。

RDS MySQL支援恢複資料到某個時間點嗎？

支援。如果已開啟記錄備份，可以恢複到記錄備份保留時間內的任意時間點；如果未開啟記錄備份，則可以恢複至已有的資料備份所在的時間點。

沒有資料備份可以按時間點恢複嗎？

不可以。因為按時間點恢複是先將所選時間點前的一個全量資料備份恢複到執行個體，然後根據Binlog增量恢複資料到所選時間點。

備份保留時間長度只設定了7天，可以恢複到更早的資料嗎

不可以，備份會在保留時間後自動刪除，無法恢複。

備份保留時間長度只設定了7天，已刪除的備份可以通過找回DMS的資料追蹤找回嗎？

無法找回，資料追蹤的本質是通過Binlog來恢複，但由於您之前的保留時間長度只設定了7天，因此無法追蹤到7天前的Binlog。您可參考自動備份文檔修改備份保留時間長度。

為什麼資料庫恢複要收費？

由於資料是恢複到新執行個體上，因此需要收取新執行個體費用，費用詳情可在建立執行個體時查看。

說明

如臨時使用，您可以建立隨用隨付或Serverless的新執行個體，把資料遷移到原執行個體，然後釋放新執行個體。
執行個體建立完成後開始計費。

恢複資料到新執行個體的時間預估需要多久？

恢複資料到新執行個體的時間取決於資料量和網路狀況，通常需要數分鐘到數小時不等。具體如下：

恢復預估樣本

測試環境：2核4 GB的高可用高效能本地碟執行個體。

操作	預計消耗時間
建立執行個體	5分鐘
配置執行個體	15分鐘
下載備份資料	200 GB/小時
啟動執行個體	5分鐘
下載Binlog	200 GB/小時
應用Binlog	根據Binlog的具體內容決定

說明

例如，恢複200 GB的資料大約需要3小時（假設下載備份資料和下載Binlog是串列的，應用Binlog消耗時間為30分鐘）。
如需更快恢複，您可以開啟沙箱執行個體，系統會自動同步資料至沙箱儲存，後續可快速恢複。詳見RDS MySQL應急恢複。

影響因素

恢複速度受多因素影響，無法保證100%成功，某些SQL異常需人工排查。影響速度的主要因素如下：

備份資料大小：資料量越大恢複速度越慢。
大事務：Binlog中存在大事務會拖慢恢複速度。
熱點更新：Binlog中存在熱點更新會拖慢恢複速度。
外鍵約束（FOREIGN KEY）：外鍵約束會增加校正成本，拖慢恢複速度。
Binlog數量：按時間點恢複時，所需的Binlog個數越多，恢複速度越慢。
儲存類型：雲端硬碟的恢複速度比高效能本地碟快。
執行個體規格：新執行個體的規格越大恢複速度越快。
執行個體版本：不同的執行個體版本並行複製的策略不同，不支援並行複製的情境都將以單線程模式進行，影響恢複速度。

重要

除上述因素外，還有可能導致恢複失敗的情況：

新執行個體版本小於源執行個體，Binlog有不能正常解析的風險。
表名或列名中包含中文、特殊字元等情況，恢複時有失敗的風險。
源執行個體中的Binlog被刪除，則無法完成恢複。
源執行個體中關閉了implicit_primary_key參數，則會導致無主鍵的表恢複失敗。

為什麼恢複時無法選擇主節點交換器？

可能因為您在前一步（基礎配置）選擇的可用性區域內沒有交換器，所以在當前步驟（網路和資源群組）無法選擇主節點交換器。您可以單擊到控制台建立跳轉到專用網路控制台，在可用性區域內建立交換器，就可以選擇主節點交換器了。

恢複位置	恢複方法
恢複到原執行個體	方法一：先恢複到新執行個體，驗證資料後，再將部分或全部庫表資料遷移至原執行個體。方法二：使用庫表恢複功能將全量資料恢複至原執行個體。方法三：使用DBS建立的邏輯備份恢複至原執行個體，請參見恢複邏輯備份。
恢複到其他已有執行個體	方法一：先恢複到新執行個體，驗證資料後，再遷移至其他已有執行個體。方法二：使用DBS建立的邏輯備份恢複至其他已有執行個體，請參見恢複邏輯備份。
恢複到本機資料庫	方法一：先恢複到新執行個體，驗證資料後，再遷移至自建資料庫。方法二：使用DBS建立的邏輯備份恢複至自建資料庫，請參見恢複邏輯備份。方法三：先下載備份，再將備份檔案恢複至自建資料庫，具體請參見RDS MySQL物理備份檔案恢複到自建資料庫、RDS MySQL邏輯備份檔案恢複到自建資料庫或RDS MySQL快照備份檔案恢複到自建資料庫。

ApsaraDB RDS：恢複全量資料