全部產品
Search
文件中心

ApsaraDB RDS:恢複全量資料

更新時間:Oct 23, 2024

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

前提條件

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

  • 執行個體運行狀態為運行中且沒有被鎖定。

  • 當前沒有進行中的遷移任務。

  • 已完成備份。RDS預設有自動備份。更多備份方式,請參見備份方案概覽

  • 按時間點恢複時,需要確保記錄備份已開啟。如何開啟,請參見RDS MySQL記錄備份

  • 按備份組恢複時,原執行個體必須至少有一個物理備份。更多資訊,請參見自動備份

功能說明

類別

說明

恢複範圍

恢複整個執行個體。

新執行個體各配置項

新執行個體的白名單設定、備份設定、參數設定和當前執行個體保持一致。

新執行個體帳號資訊

新執行個體內含恢複時所選擇的備份時間點或備份組當時的帳號資訊。

新執行個體資料

新執行個體內的資料與用於恢複的備份檔案中的資料一致。

恢複的時間點

  • 未開啟記錄備份時,只能恢複至已有的資料備份所在的時間點。

  • 開啟常規記錄備份後,可以恢複到記錄備份保留天數內,最早的一個全量備份之後的任意時間點內的資料。

  • 開啟任意時間點恢複(記錄備份升級版)後,在可任意時間點恢複天數內,可對任意時間點的資料進行恢複。

說明

恢複時間長度

恢複時間長度受多種因素影響,如果您有200 GB的資料需要恢複,恢複時間長度大概在3小時左右,恢複時間長度計算詳情請參見本文常見問題

費用說明

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

說明

功能開啟

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

操作步驟

您可以使用原執行個體的備份資料建立新執行個體進行資料恢複,該方式不會影響原執行個體的資料效能。

  1. 訪問RDS執行個體列表,在上方選擇地區,然後單擊目標執行個體ID。

  2. 在左側導覽列單擊備份恢複 > 資料庫恢複

    說明

    您也可以單擊基本資料頁面執行個體分布地區的資料庫恢複按鈕。

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

    類別

    說明

    計費方式

    • 訂用帳戶:屬於預付費,即在建立執行個體時需要支付費用。適合長期需求,價格比隨用隨付更實惠,且購買時間長度越長,折扣越多。

    • 隨用隨付:屬於後付費,即按小時計費。適合短期需求,用完可立即釋放執行個體,節省費用。

    • Serverless:屬於動態計費,即僅需要為實際用量付費。適合業務具有間歇性定時任務,負載有波動或不可預測。請參見Serverless費用

    還原方式

    • 按備份組:恢複所選備份組內的資料。暫不支援邏輯備份。

    • 按時間點:可以選擇為記錄備份保留時間內,最早的一個全量備份之後的任意時間點內的資料。如需查看或修改記錄備份保留時間,請參見自動備份

    說明

    只有開啟了記錄備份,才會顯示按時間點

    產品類型

    • 源執行個體為基礎系列時,不展示此參數。

    • 源執行個體為高可用系列時:

      • 如果儲存類型ESSD雲端硬碟通用雲端硬碟,可以選擇標準版倚天版,詳情請參見產品類型

      • 如果儲存類型本地碟,僅支援選擇標準版

    • 源執行個體為叢集系列時,可以選擇標準版倚天版

    可用性區域

    可用性區域是地區中的一個獨立物理地區,主節點可用性區域指主執行個體所在可用性區域,備節點可用性區域指備執行個體所在可用性區域。

    您可以設定執行個體為單可用性區域部署多可用性區域部署

    • 單可用性區域部署主節點可用性區域備節點可用性區域都處於相同可用性區域。

    • 多可用性區域部署(推薦):主節點可用性區域備節點可用性區域處於不同可用性區域,能提供可用性區域層級的容災。您需要手動選擇主節點可用性區域備節點可用性區域

    說明
    • 執行個體建立後,您可以在執行個體的服務可用性頁面查看主備節點資訊。

    • 基礎系列執行個體只有一個節點,只能部署在一個可用性區域內。

    執行個體規格

    • 通用規格(入門級):通用型的執行個體規格,獨享被分配的記憶體和I/O資源,與同一伺服器上的其他通用型執行個體共用CPU和儲存資源。

    • 獨享規格(企業級):獨享或獨佔型的執行個體規格。獨享型指獨享被分配的CPU、記憶體、儲存和I/O資源。獨佔型是獨享型的頂配,獨佔整台伺服器的CPU、記憶體、儲存和I/O資源。

    • 專屬規格:完全獨享虛擬機器主機或物理主機資源,開放主機許可權,可直接在主機上按需分配多個資料庫執行個體。更多資訊,請參見添加主機

    說明

    每種規格都有對應的CPU核心數、記憶體、最大串連數和最大IOPS。詳情請參見主執行個體規格列表

    儲存空間

    儲存空間包括資料空間、系統檔案空間、Binlog檔案空間和事務檔案空間。調整儲存空間時最小單位為5 GB。

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

    類別

    說明

    網路類型

    • 傳統網路:傳統的網路類型。

    • 專用網路(推薦):也稱為VPC(Virtual Private Cloud)。VPC是一種隔離的網路環境,安全性和效能均高於傳統的傳統網路。選擇專用網路時您需要選擇對應的VPC主節點交換器,如果您在上一步的基礎資源中配置了多可用性區域部署,則還需要選擇備選節點交換器

    說明

    請確保RDS執行個體與需要串連的ECS執行個體網路類型一致(如果選擇專用網路,還需要保證VPC一致),否則它們無法通過內網互連。

    資源群組

    資源群組是在阿里雲帳號下進行資源分組管理的一種機制,能夠協助您解決單個雲帳號內的資源分組和授權管理的複雜性問題。您可以選擇已有資源群組或建立新資源群組。如無資源分組管理需求,可選擇預設資源群組

  5. 單擊下一步:確認訂單

  6. 確認參數配置,選擇購買量購買時間長度(僅訂用帳戶執行個體),勾選服務合約,單擊去支付完成支付。

    說明

    對於訂用帳戶執行個體,建議勾選到期自動續約,可以免去您定期手動續約的煩惱,且不會因忘記續約而導致業務中斷。

  7. (可選)後續如需登入到新執行個體並驗證資料。關於登入執行個體的操作,請參見串連執行個體

訂正線上資料

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

說明

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

相關操作

常見問題

誤刪除了一個或多個庫,如何恢複?

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

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

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

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

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

如果備份保留時間長度只設定了7天,可以恢複到更早的資料嗎?已刪除的備份可以通過找回DMS的資料追蹤找回嗎?

不可以,因為備份都是按照您設定的保留時間進行保留的,超出保留時間後,備份都會自動刪除,無法恢複;無法找回,資料追蹤的本質是通過Binlog來恢複,但由於您之前的保留時間長度只設定了7天,因此無法追蹤到7天前的Binlog。您可參考 自動備份文檔修改備份保留時間長度。

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

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

說明

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

恢復預估樣本

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

操作

預計消耗時間

建立執行個體

5分鐘

配置執行個體

15分鐘

下載備份資料

200 GB/小時

啟動執行個體

5分鐘

下載Binlog

200 GB/小時

應用Binlog

根據Binlog的具體內容決定

說明
  • 以此樣本為例,如果您有200 GB的資料需要恢複,恢複時間長度為以上各操作消耗時間之和,大概在3小時左右(假如應用Binlog消耗時間為30分鐘)。

  • 如需更快的恢複速度,您可以開啟沙箱執行個體,系統會自動同步待恢複的資料至沙箱儲存中,後續可進行快速恢複。具體操作請參見RDS MySQL應急恢複

影響因素

恢複資料到新執行個體的速度受多種因素影響,無法保證100%恢複成功,並且使用者執行的SQL引發的某些異常情況需要人工排查處理。影響速度的主要因素如下:

  • 全量備份資料大小:資料量越大恢複速度越慢。

  • 增量備份資料大小:資料量越大恢複速度越慢。

  • 是否存在大事務:Binlog中存在大事務會拖慢恢複速度。

  • 是否存在熱點更新:Binlog中存在熱點更新會拖慢恢複速度。

  • 是否存在外鍵約束(FOREIGN KEY):外鍵約束會增加校正成本,拖慢恢複速度。

  • Binlog數量:按時間點恢複時,所需的Binlog個數越多,恢複速度越慢。

  • 執行個體的儲存類型:雲端硬碟的恢複速度比本地碟快。

  • 執行個體規格:新執行個體的規格越大恢複速度越快。

  • 執行個體版本:不同的執行個體版本並行複製的策略不同,不支援並行複製的情境都將以單線程模式進行,影響恢複速度。

重要

除上述影響恢複速度的因素以外,還有部分因素可能導致恢複無法正常進行,例如:

  • 新執行個體版本小於源執行個體,Binlog有不能正常解析的風險。

  • 表名或列名中包含中文、特殊字元等情況,恢複時有失敗的風險。

  • 若源執行個體中的Binlog被刪除,則無法完成恢複。

  • 若在源執行個體中關閉了implicit_primary_key參數,則會導致無主鍵的表恢複失敗。

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

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