一鍵遷移RDS MySQL 三節點企業系列至PolarDB-X 2.0標準版的方案概述 -

本文介紹了一鍵遷移RDS MySQL 三節點企業系列執行個體至PolarDB-X 2.0標準版執行個體的方案簡介、前提條件、使用限制、收費規則等。

遷移方案概述

將RDS MySQL 三節點企業系列執行個體一鍵遷移至PolarDB-X 2.0標準版執行個體，整個過程中將自動為您建立目標端PolarDB-X 2.0標準版執行個體並同步資料。遷移後的PolarDB-X 2.0標準版執行個體包含源RDS MySQL 三節點企業系列執行個體的帳號資訊、資料庫、IP白名單和必要的參數。

說明

RDS MySQL 三節點企業系列執行個體一鍵遷移至PolarDB-X 2.0標準版執行個體，主要採用邏輯遷移（DTS資料同步）方式實現。

邏輯遷移（DTS資料同步）方式：通過Data Transmission Service，建立資料同步任務，將源RDS MySQL 三節點企業系列執行個體的庫表結構和全量資料同步至建立的PolarDB-X 2.0標準版執行個體中，然後保持增量資料同步。

支援遷移的RDS MySQL 三節點企業系列執行個體的資料庫引擎版本和儲存類型如下：

資料庫引擎	儲存類型
MySQL 5.6、MySQL 5.7、MySQL 8.0	本地碟

遷移方案優勢

一鍵遷移方案具有如下優勢：

可保留資料庫原串連地址，無需應用程式修改任何串連配置即可切換至PolarDB-X 2.0標準版執行個體。
遷移過程完全免費。
遷移過程資料0丟失。
支援增量遷移。
支援線上熱遷移，遷移過程僅閃斷一次（即當業務從RDS MySQL 三節點企業系列執行個體切換至PolarDB-X 2.0標準版執行個體時）。
支援手動切換串連地址。切換時需要停止業務寫入，時間可以根據實際情況自行控制，通常在10分鐘以內完成。
支援復原，遷移失敗可以在10分鐘內恢複。

前提條件

源RDS MySQL 三節點企業系列執行個體的表格儲存體引擎類型為InnoDB或X-Engine。
如果RDS MySQL 三節點企業系列執行個體處於高安全模式（資料庫代理模式），需要建立有高許可權帳號（請參見建立帳號），或者切換到高效能模式（參見【產品/功能變更】RDS網路鏈路升級說明），才能進行一鍵遷移。

使用限制

僅支援將RDS MySQL 三節點企業系列執行個體一鍵遷移至相同版本或更高版本的PolarDB-X 2.0標準版執行個體，不支援降版本遷移。
帶地址切換中，當前不支援IPv6地址的帶地址切換。

邏輯遷移（DTS資料同步）方式的使用限制如下：

暫不支援跨地區遷移。
遷移期間不允許對源RDS MySQL 三節點企業系列執行個體執行參數設定的操作。
僅支援遷移庫、表、視圖、預存程序、函數這五類結構。
說明
源RDS MySQL 三節點企業系列執行個體的帳號資訊、IP白名單和必要的參數的遷移工作由PolarDB-X完成，而非Data Transmission Service。

對源庫有如下限制：

類型

說明

源庫限制

待同步的表需具備主鍵或唯一約束，且欄位具有唯一性，否則可能會導致目標資料庫中出現重複資料。
- 如同步對象為表層級，且需進行編輯（如表列名映射），則單次同步任務僅支援同步至多1000張表。當超出數量限制，任務提交後會顯示請求報錯，此時建議您拆分待同步的表，分批配置多個任務，或者配置整庫的同步任務。
- Binlog日誌：
  - 需開啟Binlog，開啟方法請參見設定執行個體參數，並且binlog_row_image為full。否則，在預檢查階段就會提示報錯，且無法成功啟動資料同步任務。
  - 如為增量同步處理任務，DTS要求來源資料庫的本地Binlog日誌儲存24小時以上，如為全量同步和增量同步處理任務，DTS要求來源資料庫的本地Binlog日誌至少保留7天以上（您可在全量同步完成後將Binlog儲存時間設定為24小時以上），否則DTS可能因無法擷取Binlog而導致任務失敗，極端情況下甚至可能會導致資料不一致或丟失。由於您所設定的Binlog日誌儲存時間低於DTS要求的時間進而導致的問題，不在DTS的SLA保障範圍內。如源為RDS MySQL 三節點企業系列執行個體，具體操作請參見管理本地日誌（Binlog）。

SQL語句限制：

操作類型	SQL語句
DML	INSERT、UPDATE、DELETE
DDL	ALTER TABLE、ALTER VIEW CREATE FUNCTION、CREATE INDEX、CREATE PROCEDURE、CREATE TABLE、CREATE VIEW DROP INDEX、DROP TABLE RENAME TABLE TRUNCATE TABLE

其他限制：

類型

說明

其他限制

執行資料同步前需評估源庫和目標庫的效能，同時建議業務低峰期執行資料同步。否則全量資料初始化時將佔用源庫和目標庫一定的讀寫資源，可能會導致資料庫的負載上升。
全量初始化會並發執行INSERT操作，導致目標資料庫的表產生片段，因此全量初始化完成後目標執行個體的資料表空間比源執行個體的資料表空間大。
在DTS同步期間，不允許有除DTS外的資料寫入目標庫，否則會導致源庫與目標庫資料不一致。例如，有除DTS外的資料寫入目標庫時，使用DMS執行線上DDL變更，可能引起目標庫資料丟失。
DTS預設同步到目標資料庫時會取消外鍵約束，因此來源資料庫的級聯、刪除等操作不會同步到目標資料庫。

注意事項

源RDS MySQL 三節點企業系列執行個體和目標PolarDB-X 2.0標準版執行個體對應串連地址的SSL開啟狀態需保持一致：

如果源RDS MySQL 三節點企業系列執行個體的串連地址開啟了SSL，並且您選擇帶地址切換並切換該地址，請確保PolarDB-X 2.0標準版執行個體對應的串連地址同樣已開啟SSL。
如果源RDS MySQL 三節點企業系列執行個體的串連地址未開啟SSL，則請確保目標PolarDB-X 2.0標準版執行個體對應串連地址的SSL功能也保持關閉。

收費規則

一鍵遷移方案中，遷移過程完全免費，僅收取目標PolarDB-X 2.0標準版執行個體的費用。

備份策略說明

PolarDB-X 2.0標準版執行個體的常規備份周期、備份開始時間與RDS MySQL 三節點企業系列執行個體的常規備份周期、備份開始時間保持一致。

遷移完成後，您可以修改PolarDB-X 2.0標準版執行個體的備份策略。

帶地址切換

一鍵遷移RDS MySQL 三節點企業系列執行個體至PolarDB-X 2.0標準版執行個體時支援帶地址切換，系統會自動交換RDS MySQL 三節點企業系列執行個體和PolarDB-X 2.0標準版執行個體上的串連地址，您無需在應用程式端修改任何配置即可自動連接到PolarDB-X 2.0標準版執行個體。選擇該切換方式後，RDS MySQL 三節點企業系列執行個體串連地址對應的PolarDB-X 2.0標準版執行個體串連地址如下圖所示。

使用帶地址切換功能時，需注意以下幾點：

帶地址切換隻會切換RDS MySQL 三節點企業系列執行個體和PolarDB-X 2.0標準版執行個體的串連地址，vSwitch、VIP等配置不會切換。
僅當源RDS MySQL 三節點企業系列執行個體和目標PolarDB-X 2.0標準版執行個體同時存在的串連地址才支援相互切換，預設情況下僅私網主地址支援帶地址切換。
當前不支援IPv6的地址帶地址切換。
帶地址切換不會切換連接埠，請確保RDS MySQL 三節點企業系列執行個體和PolarDB-X 2.0標準版執行個體的串連連接埠一致（RDS MySQL 三節點企業系列執行個體和PolarDB-X 2.0標準版執行個體預設使用的連接埠號碼均為3306），如需修改連接埠，請參見查看和管理執行個體串連地址和連接埠。
切換串連地址後，可能會存在DNS解析緩衝問題，在緩衝到期時間內可能會出現串連不上資料庫或資料庫只支援讀操作無法執行寫入操作等情況，建議您重新整理一下伺服器的DNS緩衝。
說明
請根據您伺服器實際作業系統及版本進行DNS重新整理操作。以Alibaba Cloud Linux 2/3為例，可以使用如下方式進行主動重新整理DNS緩衝：
1. 首先，請檢查systemd-resolved是否正在運行。如果服務正在運行，您將會看到類似於Active: active (running)的狀態資訊。
```
sudo systemctl status systemd-resolved
```
2. 重新整理systemd-resolved的DNS緩衝。
```
sudo systemd-resolve --flush-caches
```
切換串連地址後，如果您需要使用DMS登入PolarDB-X 2.0標準版執行個體資料庫，必須使用新版本的DMS並且使用PolarDB-X 2.0標準版執行個體ID來進行登入，使用串連串地址無法登入。