使用 AWS DMS 將來源 RDS MySQL 資料庫遷移至目標 RDS MySQL 資料庫時，應遵循哪些最佳實務？

簡短描述

使用 AWS DMS，您可以從來源資料存放區將資料遷移至目標資料存放區。這兩個資料存放區稱為端點。您可以在使用相同資料庫引擎的來源端點和目標端點之間遷移，例如從一個 MySQL 資料庫遷移至另一個 MySQL 資料庫。

雖然 AWS DMS 會建立目標結構描述物件，但其只會建立從來源有效遷移資料所需的最小物件。因此，AWS DMS 會建立資料表、主索引鍵，並在某些情況下建立唯一索引，但不會建立如次要索引、非主索引鍵條件約束和資料預設值的物件。如需 AWS DMS 遷移內容的詳細資訊，請參閱 AWS DMS 的高階檢視 。

遷移前，在目標資料庫上預先建立資料表

若要保留預設資料定義，請於遷移前在目標資料庫上預先建立資料表。根據您執行的遷移類型，使用下列其中一種方法：

• 對於諸如 MySQL 到 MySQL 之類的同性質遷移，請使用本機資料庫引擎公用程序 (例如 mysqldump) 來導出資料表定義。然後，將這些資料表定義導入到目標中，而不包含資料。建立資料表定義後，請使用 AWS DMS 任務並將目標資料表準備模式設為 TRUNCATE_BEFORE_LOAD 來載入資料。
• 對於跨不同資料庫引擎的遷移，請使用 AWS Schema Conversion Tool (AWS SCT)。您也可以將此方法用於同性質的資料庫。AWS SCT 會連線到您的來源和目標資料庫，然後將現有的資料庫結構描述從一個資料庫引擎轉換至另一個資料庫引擎。您可以使用 AWS SCT 在目標資料庫上預先建立資料表，同時保持預設資料定義完整無缺。然後，請使用 AWS DMS 任務並將目標資料表準備模式設為 TRUNCATE_BEFORE_LOAD 來載入資料。如需詳細資訊，請參閱利用 AWS SCT 轉換您的結構描述。

解析度

遵循 MySQL 到 MySQL AWS DMS 遷移的最佳實務

將資料從 MySQL 來源資料庫遷移至 MySQL 目標資料庫時，請使用這些最佳實務。

• 在遷移期間，請關閉目標資料庫上的備份和資料庫特定日誌 (例如二進位、一般和稽核)。如有需要，您可以再次將其開啟以解決問題。
• 在遷移期間，關閉目標資料庫上的觸發器、其他 Cron 工作和事件排程器。
• 執行 AWS DMS 遷移時，請避免在目標 Amazon RDS 資料庫上使用異地同步備份。
• 執行遷移時，請避免將任何其他外部用戶端流量套用至目標資料庫。
• 使用所需的 CPU、記憶體、儲存器和 IOPS 佈建 AWS DMS 複寫執行個體、來源和目標資料庫，以避免在遷移期間發生資源爭用。
• 在開始遷移前，請先使用 AWS DMS 變更資料擷取 (CDC) 的先決條件設定來源資料庫。
• 使用最佳化 LOB 設定，例如限制 LOB 和內嵌 LOB 來進行遷移。
• 如果來源資料庫包含許多工作負載繁重的資料表，請在多個任務間分割資料表。根據來源資料庫、應用程式流量模式和 LOB 資料欄的存在大小來分割資料表。如果資料表在來源上有許多 LOB (TEXT 或 JSON) 資料欄，且具有高寫入流量，請為資料表建立個別的任務。任務內維護交易的一致性，因此，單獨任務中的資料表不參與一般的交易非常重要。
• 針對大量來源資料表使用平行完整載入機制，以減少遷移時間。如需詳細資訊，請參閱針對選取的資料表、檢視表和集合使用平行載入。
• 在完整載入遷移期間，關閉目標資料表上的外來索引鍵條件約束。
• 在開始複寫的 CDC 階段前，先在目標資料庫上新增次要索引。
• Amazon RDS 主要使用者在預設結構描述資料表上沒有刪除和重新建立權限。因此，請避免使用 AWS DMS 從來源遷移預設資料庫或結構描述資料表。
• 請參閱有關使用 AWS DMS 將資料從 MySQL 遷移至 MySQL 的文件，瞭解 AWS DMS 可成功遷移哪些資料類型的相關資訊。
• 使用批次套用 CDC 方法前，請先使用預設交易 CDC 套用測試工作負載。如需詳細資訊，請參閱如何使用 DMS 批次套用功能來提高 CDC 複寫效能？
• 在開始生產遷移前，在任何其他 QA/DEV 資料庫環境上使用相同的生產資料測試遷移。進行生產遷移時，請務必使用相同的 AWS DMS 組態。

如需詳細資訊，請參閱改善 AWS DMS 遷移的效能。

在來源和目標資料庫上使用建議的組態和方法

1.在目標 MySQL/PostgreSQL 資料庫上手動預先建立資料表 DDL。然後，在目標準備模式設定為 DO_DOTHING”/"TRUNCATE 的情況下，建立 AWS DMS 任務以僅遷移資料。

執行此命令以建立不含來源 MySQL 資料庫之資料的轉存：

mysqldump -h yourhostnameorIP -u root -p --no-data --skip-triggers --single-transaction --dbname > schema.sql

此命令會從來源轉存 DDL 結構，而不會有任何資料。

接下來，執行此命令以還原目標上的 DDL 結構：

mysql -u user -p -h yourhostnameorIP  database_name < schema.sql

或者，您可以允許 AWS DMS 使用「刪除並建立」目標準備模式在目標上建立資料表。接著，跳至步驟 3 以變更資料並新增遺失的物件 (例如次要索引)，然後再繼續 CDC 階段的任務。

**注意：**根據預設，AWS DMS 只會使用主索引鍵或唯一索引鍵在目標上建立資料表。不會將任何其他物件遷移至目標 MySQL 資料庫。

2.在完整載入期間，AWS DMS 不會識別外部索引鍵關聯式資料表。其會隨機載入資料，因此如果目標資料庫開啟外部索引鍵檢查，資料表載入可能會失敗。在目標 MySQL 端點上使用此額外連線屬性 (ECA)，可關閉此 AWS DMS 工作階段的外部索引鍵檢查。

initstmt=SET FOREIGN_KEY_CHECKS=0;

如需詳細資訊，請參閱使用與 MySQL 相容的資料庫做為 AWS DMS 目標時的額外連線屬性。

3.在 JSON 設定中，在將快取變更套用於 true 前設定停止任務，並在將快取變更套用於 true 後停止任務。

"FullLoadSettings": {
    "TargetTablePrepMode": "TRUNCATE_BEFORE_LOAD"
    "CreatePkAfterFullLoad": false,
    "TransactionConsistencyTimeout": 600,
    "MaxFullLoadSubTasks": 8,
    "StopTaskCachedChangesNotApplied": true,   <--- set this to true
    "StopTaskCachedChangesApplied": true,    <--- set this to true
    "CommitRate": 50000,
}

完整載入完成後，以及在套用快取變更前，任務就會停止。當任務停止時，請在目標上建立主索引鍵索引和次要索引。

接下來，繼續任務，因為任務會在套用快取變更後再次停止。然後，在 CDC 複寫階段再次繼續任務前，使用 AWS DMS 驗證輸出或手動驗證來核對遷移的資料。透過完成此步驟，您可以在繼續進行 CDC 複寫前找出任何問題並加以解決。

4.    在任務完整載入設定中，調整 commitRate 設定，以加快來源的資料擷取速率。預設值為 10000，因此當您從來源資料表遷移大量資料時，請調整此設定。

CommitRate=50000

注意：將 commitRate 變更為較高的值可能會影響效能，因此請務必在複寫執行個體中監控並擁有足夠的記憶體。

5.    在目標端點上新增此 ECA，以指定用於將資料傳輸至目標 MySQL 的任何 .csv 檔案大小上限 (以 KB 為單位)。預設值為 32768 KB (32 MB)，有效值的範圍介於 1 至 1048576 KB 之間 (最大 1.1 GB)。

maxFileSize=250000;

附註：當您使用目標執行個體 (例如 MySQL、Aurora 或 MariaDB) 進行完整載入時，請使用此選項允許 AWS DMS 在背景建立 .csv 檔案，將資料載入目標執行個體。請使用介於 32 MB 到 1 GB 之間的值。但是，還要考慮您的目標執行個體可以處理的容量。如果您有多個任務載入 1 GB 的 .csv 檔案，這可能會造成目標執行個體的額外負擔。請確定您的目標具有高運算能力的執行個體。

6.    使用有限的 LOB 或內嵌 LOB 設定以獲得更好的效能。

**有限的 LOB 模式：**使用有限的 LOB 模式時，您可以指定 LOB 資料欄資料的大小上限。這可讓 AWS DMS 預先配置資源，然後大量套用 LOB。如果 LOB 資料欄的大小超過您在任務中指定的大小，AWS DMS 會截斷資料。然後，AWS DMS 會將警告傳送到 AWS DMS 日誌檔案。使用有限的 LOB 模式可改善效能，不過，在執行任務前，必須先確定來源上資料的 LOB 大小上限。然後，指定 LOB 大小上限參數。此為確保您有足夠的記憶體配置給複寫執行個體來處理任務的最佳實務。

**內嵌 LOB 模式：**使用內嵌 LOB 模式時，您可以透過複寫小型和大型 LOB 來遷移 LOB，而不會截斷資料或降低任務效能。首先，指定 InlineLobMaxSize 參數的值，此參數只有在完整 LOB 模式設定為 true 時才可用。AWS DMS 任務會以內嵌方式傳輸小型 LOB，這樣更有效率。然後，AWS DMS 會透過從來源資料表執行查閱，在完整 LOB 模式下遷移大於指定大小的 LOB。不過請注意，內嵌 LOB 模式只能在完整載入階段運作。

**注意：**當您指定任務的任務設定時，您必須設定 InlineLobMaxSize。

執行這些查詢以檢查 LOB 大小，然後填入 LOB 大小上限。

列出具有 LOB 資料欄的資料表：

select tab.table_name,
count(*) as columns
from information_schema.tables as tab
inner join information_schema.columns as col
on col.table_schema = tab.table_schema
and col.table_name = tab.table_name
and col.data_type in ('blob', 'mediumblob', 'longblob',
'text', 'mediumtext', 'longtext')
where tab.table_schema = 'your database name'.  <---- enter database name here
and tab.table_type = 'BASE TABLE'
group by tab.table_name
order by tab.table_name;

檢查 LOB 資料欄的大小：

Select (max(length (<COL_NAME>))/(1024)) as “size in KB” from <TABLE_NAME>;

檢查所有資料表的 LOB 資料欄大小，然後以 LOB 大小上限 (K) 填入大小上限。

使用值大於 63 KB 的 LOB 大小 (K) 上限選項，會影響設定為在有限的 LOB 模式下執行的完整載入效能。在完整載入期間，AWS DMS 會將 LOB 大小 (k) 上限值乘以認可率來配置記憶體。然後，該產品乘以 LOB 資料欄的數量。

當 AWS DMS 無法預先配置該記憶體時，AWS DMS 會開始消耗 SWAP 記憶體。這會影響完整載入的效能。因此，如果您在使用有限的 LOB 模式時遇到效能問題，請降低認可率，直到達到可接受的效能等級為止。或者，在第一次檢查資料表的 LOB 分佈後，請考慮針對支援的端點使用內嵌 LOB 模式。

如需詳細資訊，請參閱在 AWS DMS 任務中設定來源資料庫的 LOB 支援。

---

相關資訊

使用 AWS DMS 從 MySQL 遷移至 Amazon RDS

資料庫遷移逐步解說