MySQL 至適用於 MySQL 的 Azure 資料庫資料移轉 - MySQL 複寫變更

執行複寫變更移轉，我們的離線案例具有「啟用交易一致性」，可讓企業在資料庫維持運作的同時，將其資料庫移轉至 Azure。 換句話說，針對重要的應用程式，可以在停機時間最短的情況下完成移轉，以限制對服務等級可用性的影響以及對其終端客戶的不便。

注意

本文包含「從屬」一詞的參考，Microsoft 已不再使用該字詞。 從軟體中移除該字詞時，我們也會將其從本文中移除。

目前的實作

您必須執行具有「啟用交易一致性」的離線移轉案例，以取得二進位記錄檔和位置，以復寫傳入的變更。 DMS 入口網站 UI 會顯示二進位記錄檔的檔案名稱，並對齊為了一致快照集而在來源上取得鎖定時的位置。 您可以在復寫變更移轉中使用此值，以串流傳入的變更。

執行復寫變更移轉時，當目標幾乎趕上來源伺服器時，請停止來源資料庫的所有傳入交易，並等到所有擱置的交易都套用至目標資料庫為止。 若要確認目標資料庫在來源伺服器上是最新狀態，請執行查詢 'SHOW MASTER STATUS;'，然後將該位置與最後一個認可的 Binlog 事件 (顯示在 [移轉進度] 底下) 進行比較。 當兩個位置相同時，目標已趕上所有變更，而您可以開始完全移轉。

複寫變更的運作方式

目前的實作是以來源伺服器的串流 Binlog 變更為基礎，並將其套用至目標伺服器。 這會更容易設定，正如資料輸入複寫一樣，而且不需要來源與目標伺服器之間的實體連線。

伺服器可以將 Binlog 傳送為串流，其中包含二進位資料，如這裡記載。 用戶端可以指定要啟動串流的初始記錄位置。 記錄檔案名稱會描述記錄位置、該檔案中的位置，以及選擇性全域交易識別碼 (GTID) (在來源啟用 gtid 模式時)。

資料變更會以「資料列」事件的形式傳送，其中包含個別資料列的資料 (根據插入、刪除或更新的作業類型來決定在變更之前和/或之後)。 然後，會使用 BINLOG 陳述式以原始格式套用資料列事件： MySQL 8.0 參考手冊：：13.7.8.1 BINLOG 陳述式。 但是對於 DMS 移轉至 5.7 伺服器，DMS 不會將變更套用為 BINLOG 陳述式 (因為 DMS 沒有執行此動作的必要權限)，而是會將資料列事件轉譯成 INSERT、UPDATE 或 DELETE 陳述式。

必要條件

若要順利完成復寫變更移轉，請確定已備妥下列必要條件：

• 使用您選擇的 MySQL 命令列工具來判斷來源伺服器的 log_bin 是否已啟用。 預設情況下，Binlog 並不總是開啟，因此請在開始移轉之前確認它已啟用。 若要判斷來源伺服器上是否已啟用 log_bin，請執行以下命令：SHOW VARIABLES LIKE 'log_bin'
• 確保使用者在目標伺服器上具有 "REPLICATION_APPLIER" 或 "BINLOG_ADMIN" 權限以套用二進位記錄檔。
• 確保使用者在目標伺服器上具有 "REPLICATION SLAVE" 權限。
• 確保使用者在來源伺服器上具有 "REPLICATION CLIENT" 和 "REPLICATION SLAVE" 權限以讀取和套用二進位記錄檔。
• 執行具有「啟用交易一致性」的離線移轉案例，以取得二進位記錄檔和位置。
• 如果您的目標是複寫變更移轉，請在來源伺服器上設定 binlog_expire_logs_seconds 參數，以確保在複本認可變更之前不會清除 Binlog 檔案。 首先，我們建議至少兩天。 完全移轉成功後，可以重設該值。

限制

• 執行複寫變更移轉時，目標伺服器上的資料庫名稱必須與來源伺服器上的資料庫名稱相同。
• 支援僅限於 ROW Binlog 格式。
• 只有當您在 DMS UI 上選取了 [複寫所選物件的資料定義和管理陳述式] 選項時，才支援 DDL 變更複寫。 複寫功能支援複寫初始載入後發生的資料定義和管理陳述式，並將其記錄在目標的二進位記錄中。
• 複寫變更時不支援重新命名資料庫或資料表。

相關內容

• 教學課程：使用 DMS 離線將 MySQL 移轉至適用於 MySQL 的 Azure 資料庫