如果遷移的來源資料庫類型為MySQL，如自建MySQL、RDS MySQL，您需要在配置具體的遷移任務前，參考本文的注意事項及限制，以保障資料移轉任務的正常運行。
源庫為MySQL的遷移方案概覽
根據如下遷移方案，查看遷移任務的注意事項及限制：
MySQL間的遷移
如果遷移的目標資料庫類型為MySQL，如RDS MySQL、自建MySQL，具體注意事項及限制如下：
|
類型
|
說明
|
|
源庫限制
|
-
頻寬要求：源庫所屬的伺服器需具備足夠出口頻寬，否則將影響資料移轉速率。
-
待遷移的表需具備主鍵或唯一約束，且欄位具有唯一性，否則可能會導致目標資料庫中出現重複資料。
-
如遷移對象為表層級，且需進行編輯（如表列名映射），則單次遷移任務僅支援遷移至多1000張表。當超出數量限制，任務提交後會顯示請求報錯，此時建議您拆分待遷移的表，分批配置多個任務，或者配置整庫的遷移任務。
-
如需進行增量遷移，Binlog日誌：
-
需開啟，並且binlog_format為row、binlog_row_image為full。否則預檢查階段提示報錯，且無法成功啟動資料移轉任務。
重要
如源執行個體自建MySQL是雙主叢集（兩者互為主從），為保障DTS能擷取全部的Binlog日誌，則您需開啟參數log_slave_updates。
-
RDS MySQL執行個體的本地Binlog日誌需保留3天及以上（建議保留7天），自建MySQL資料庫的本地Binlog日誌需保留7天及以上。否則DTS可能會因無法擷取Binlog而導致任務失敗，極端情況下甚至可能會導致資料不一致或資料丟失。由於您所設定的Binlog日誌儲存時間低於DTS要求的時間而導致的問題，不在DTS的SLA保障範圍內。
說明
RDS MySQL執行個體的本地Binlog日誌保留時間長度的設定方法，請參見自動刪除本地日誌。
-
源庫的操作限制：
-
在遷移執行個體運行期間，不記錄Binlog的變更操作所產生的資料（例如通過物理備份功能恢複、級聯操作等產生的資料），不會被遷移到目標庫。
說明
若有該情況，您可以在業務允許的前提下，重新遷移全量資料。
-
若源庫為8.0.23及以後版本的MySQL資料庫，且待遷移的資料中包含不可見的隱藏列，則可能會因為無法擷取該列的資料而導致資料丟失。
說明
您可以使用ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;命令，將該隱藏列設定為可見。更多資訊，請參見Invisible Columns。
|
|
其他限制
|
-
建議源和目標庫的MySQL版本保持一致，以保障相容性。
-
若源庫有暫存資料表模式的Online DDL變更操作（包括但不限於多表合并情境）或對唯一鍵列添加函數索引，則可能導致目標庫資料丟失或遷移執行個體運行失敗。
-
不支援遷移使用注釋文法定義的解析器（Parser）。
-
若在遷移執行個體運行時遇到主鍵或唯一鍵衝突：
-
若目標庫為8.0.23及以後版本的MySQL資料庫，且接收資料的列中包含不可見的隱藏列，則可能會因為無法找到寫入資料的目標列，導致DTS執行個體運行失敗或資料丟失。
說明
您可以使用ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;命令，將該隱藏列設定為可見。更多資訊，請參見Invisible Columns。
-
若您遷移資料時未使用DTS提供的庫表結構遷移，則需要自行確保欄位的相容性，否則可能會導致執行個體失敗或資料丟失。例如，當源表的欄位為text類型，而接收資料的目標欄位的類型為varchar(255)時，若源表中存在大欄位，則可能會導致資料截斷。
-
若待遷移的資料中包含需要四位元組儲存的內容（例如生僻字、表情等資訊），則目標端接收資料的資料庫和表必須使用utf8mb4字元集。
說明
若您使用DTS遷移庫表結構，則需將目標庫中執行個體層級的參數character_set_server設定為utf8mb4。
-
執行資料移轉前需評估源庫和目標庫的效能，同時建議業務低峰期執行資料移轉。否則全量資料移轉時DTS佔用源和目標庫一定讀寫資源，可能會導致資料庫的負載上升。
-
由於全量資料移轉會並發執行INSERT操作，導致目標資料庫的表產生片段，因此全量遷移完成後目標資料庫的表格儲存體空間會比源執行個體的表格儲存體空間大。
-
請確認DTS對資料類型為FLOAT或DOUBLE的列的遷移精度是否符合業務預期。DTS會通過ROUND(COLUMN,PRECISION)來讀取這兩類列的值。如果沒有明確定義其精度，DTS對FLOAT的遷移精度為38位，對DOUBLE的遷移精度為308位。
-
DTS會嘗試恢複七天之內遷移失敗任務。因此，在業務切換至目標執行個體前，請務必結束或釋放該任務，或者使用revoke命令回收DTS訪問目標執行個體帳號的寫入權限。避免該任務被自動回復後，源端資料覆蓋目標執行個體的資料。
-
若目標庫的DDL寫入失敗，DTS任務會繼續運行，您需要在任務日誌中查看執行失敗的DDL。查看任務日誌的方法，請參見查詢任務日誌。
-
若您將列名僅大小寫不同的欄位寫入到目標MySQL資料庫的同一個表中，可能會因為MySQL資料庫列名大小寫不敏感，導致遷移結果不符合預期。
-
在資料移轉完成後（執行個體的運行狀態為已完成），建議使用analyze table <表名>命令以確認資料均已寫入目標表。例如，在目標MySQL資料庫觸發HA切換機制後，可能會導致資料唯寫到了記憶體，從而造成資料丟失。
-
若RDS MySQL執行個體已開通全密態（EncDB）功能，則不支援全量資料移轉。
說明
開啟透明資料加密TDE（Transparent Data Encryption）功能的RDS MySQL執行個體支援庫表結構遷移、全量資料移轉和增量資料移轉。
-
若您需要遷移源庫中的帳號，則還需滿足相應的前提條件，並瞭解相關注意事項。更多資訊，請參見遷移資料庫帳號。
-
若執行個體運行失敗，DTS技術支援人員將在8小時內嘗試恢複該執行個體。在恢複失敗執行個體的過程中，可能會對該執行個體進行重啟、調整參數等操作。
說明
在調整參數時，僅會修改DTS執行個體的參數，不會對資料庫中的參數進行修改。可能修改的參數，包括但不限於修改執行個體參數中的參數。
|
|
特殊情況
|
|
MySQL遷移至PolarDB MySQL版
如果遷移的目標庫為PolarDB MySQL版，具體注意事項及限制如下：
|
類型
|
說明
|
|
源庫限制
|
-
頻寬要求：源庫所屬的伺服器需具備足夠出口頻寬，否則將影響資料移轉速率。
-
待遷移的表需具備主鍵或唯一約束，且欄位具有唯一性，否則可能會導致目標資料庫中出現重複資料。
-
如遷移對象為表層級，且需進行編輯（如表列名映射），則單次遷移任務僅支援遷移至多1000張表。當超出數量限制，任務提交後會顯示請求報錯，此時建議您拆分待遷移的表，分批配置多個任務，或者配置整庫的遷移任務。
-
如需進行增量遷移，Binlog日誌：
-
需開啟，並且binlog_format為row、binlog_row_image為full。否則預檢查階段提示報錯，且無法成功啟動資料移轉任務。
重要
如源執行個體自建MySQL是雙主叢集（兩者互為主從），為保障DTS能擷取全部的Binlog日誌，則您需開啟參數log_slave_updates。
-
RDS MySQL執行個體的本地Binlog日誌需保留3天及以上（建議保留7天），自建MySQL資料庫的本地Binlog日誌需保留7天及以上。否則DTS可能會因無法擷取Binlog而導致任務失敗，極端情況下甚至可能會導致資料不一致或資料丟失。由於您所設定的Binlog日誌儲存時間低於DTS要求的時間而導致的問題，不在DTS的SLA保障範圍內。
說明
RDS MySQL執行個體的本地Binlog日誌保留時間長度的設定方法，請參見自動刪除本地日誌。
-
源庫的操作限制：
-
在遷移執行個體運行期間，不記錄Binlog的變更操作所產生的資料（例如通過物理備份功能恢複、級聯操作等產生的資料），不會被遷移到目標庫。
說明
若有該情況，您可以在業務允許的前提下，重新遷移全量資料。
-
若源庫為8.0.23及以後版本的MySQL資料庫，且待遷移的資料中包含不可見的隱藏列，則可能會因為無法擷取該列的資料而導致資料丟失。
說明
您可以使用ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;命令，將該隱藏列設定為可見。更多資訊，請參見Invisible Columns。
|
|
其他限制
|
-
建議源和目標庫的MySQL版本保持一致，以保障相容性。
-
若源庫有暫存資料表模式的Online DDL變更操作（包括但不限於多表合并情境）或對唯一鍵列添加函數索引，則可能導致目標庫資料丟失或遷移執行個體運行失敗。
-
不支援遷移使用注釋文法定義的解析器（Parser）。
-
若在遷移執行個體運行時遇到主鍵或唯一鍵衝突：
-
執行資料移轉前需評估源庫和目標庫的效能，同時建議業務低峰期執行資料移轉。否則全量資料移轉時DTS佔用源和目標庫一定讀寫資源，可能會導致資料庫的負載上升。
-
由於全量資料移轉會並發執行INSERT操作，導致目標資料庫的表產生片段，因此全量遷移完成後目標資料庫的表格儲存體空間會比源執行個體的表格儲存體空間大。
-
若待遷移的資料中包含需要四位元組儲存的內容（例如生僻字、表情等資訊），則目標端接收資料的資料庫和表必須使用utf8mb4字元集。
說明
若您使用DTS遷移庫表結構，則需將目標庫中執行個體層級的參數character_set_server設定為utf8mb4。
-
請確認DTS對資料類型為FLOAT或DOUBLE的列的遷移精度是否符合業務預期。DTS會通過ROUND(COLUMN,PRECISION)來讀取這兩類列的值。如果沒有明確定義其精度，DTS對FLOAT的遷移精度為38位，對DOUBLE的遷移精度為308位。
-
DTS會嘗試恢複七天之內遷移失敗任務。因此，在業務切換至目標執行個體前，請務必結束或釋放該任務，或者使用revoke命令回收DTS訪問目標執行個體帳號的寫入權限。避免該任務被自動回復後，源端資料覆蓋目標執行個體的資料。
-
不支援將datetime類型的資料轉為varchar。
-
若目標庫的DDL寫入失敗，DTS任務會繼續運行，您需要在任務日誌中查看執行失敗的DDL。查看任務日誌的方法，請參見查詢任務日誌。
-
若RDS MySQL執行個體已開通全密態（EncDB）功能，則不支援全量資料移轉。
說明
開啟透明資料加密TDE（Transparent Data Encryption）功能的RDS MySQL執行個體支援庫表結構遷移、全量資料移轉和增量資料移轉。
-
若您需要遷移源庫中的帳號，則還需滿足相應的前提條件，並瞭解相關注意事項。更多資訊，請參見遷移資料庫帳號。
-
若執行個體運行失敗，DTS技術支援人員將在8小時內嘗試恢複該執行個體。在恢複失敗執行個體的過程中，可能會對該執行個體進行重啟、調整參數等操作。
說明
在調整參數時，僅會修改DTS執行個體的參數，不會對資料庫中的參數進行修改。可能修改的參數，包括但不限於修改執行個體參數中的參數。
|
|
特殊情況
|
-
當源庫為自建MySQL時：
-
遷移時源庫進行主備切換，會導致遷移任務失敗。
-
由於DTS的延遲時間是根據遷移到目標庫最後一條資料的時間戳記和目前時間戳對比得出，源庫長時間未執行DML操作可能導致延遲資訊不準確。如果任務顯示的延遲時間過大，您可以在源庫執行一個DML操作來更新延遲資訊。
說明
如果遷移對象選擇為整庫，您還可以建立心跳錶，心跳錶每秒定期更新或者寫入資料。
-
DTS會在源庫定時執行CREATE DATABASE IF NOT EXISTS `test`命令以推進Binlog位點。
-
若源庫為Amazon Aurora MySQL或其他叢集模式的MySQL執行個體，請確保任務配置的網域名稱或IP地址及其解析結果為始終為RW（讀寫）節點地址，否則可能會導致遷移任務無法正常運行。
-
-
當目標庫為PolarDB MySQL版時：
|
MySQL遷移至PolarDB-X 2.0
具體注意事項及限制如下：
|
類型
|
說明
|
|
源庫限制
|
-
頻寬要求：源庫所屬的伺服器需具備足夠出口頻寬，否則將影響資料移轉速率。
-
待遷移的表需具備主鍵或唯一約束，且欄位具有唯一性，否則可能會導致目標資料庫中出現重複資料。
-
如遷移對象為表層級，且需進行編輯（如表列名映射），則單次遷移任務僅支援遷移至多1000張表。當超出數量限制，任務提交後會顯示請求報錯，此時建議您拆分待遷移的表，分批配置多個任務，或者配置整庫的遷移任務。
-
如需進行增量遷移，Binlog日誌：
-
需開啟，並且binlog_format為row、binlog_row_image為full。否則預檢查階段提示報錯，且無法成功啟動資料移轉任務。
重要
如源執行個體自建MySQL是雙主叢集（兩者互為主從），為保障DTS能擷取全部的Binlog日誌，則您需開啟參數log_slave_updates。
-
RDS MySQL執行個體的本地Binlog日誌需保留3天及以上（建議保留7天），自建MySQL資料庫的本地Binlog日誌需保留7天及以上。否則DTS可能會因無法擷取Binlog而導致任務失敗，極端情況下甚至可能會導致資料不一致或資料丟失。由於您所設定的Binlog日誌儲存時間低於DTS要求的時間而導致的問題，不在DTS的SLA保障範圍內。
說明
RDS MySQL執行個體的本地Binlog日誌保留時間長度的設定方法，請參見自動刪除本地日誌。
-
源庫的操作限制：
-
在遷移執行個體運行期間，不記錄Binlog的變更操作所產生的資料（例如通過物理備份功能恢複、級聯操作等產生的資料），不會被遷移到目標庫。
說明
若有該情況，您可以在業務允許的前提下，重新遷移全量資料。
-
若源庫為8.0.23及以後版本的MySQL資料庫，且待遷移的資料中包含不可見的隱藏列，則可能會因為無法擷取該列的資料而導致資料丟失。
說明
您可以使用ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;命令，將該隱藏列設定為可見。更多資訊，請參見Invisible Columns。
|
|
其他限制
|
-
若在遷移執行個體運行時遇到主鍵或唯一鍵衝突：
-
若源庫有暫存資料表模式的Online DDL變更操作（包括但不限於多表合并情境）或對唯一鍵列添加函數索引，則可能導致目標庫資料丟失或遷移執行個體運行失敗。
-
執行資料移轉前需評估源庫和目標庫的效能，同時建議業務低峰期執行資料移轉。否則全量資料移轉時DTS佔用源和目標庫一定讀寫資源，可能會導致資料庫的負載上升。
-
由於全量資料移轉會並發執行INSERT操作，導致目標資料庫的表產生片段，因此全量遷移完成後目標資料庫的表格儲存體空間會比源執行個體的表格儲存體空間大。
-
請確認DTS對資料類型為FLOAT或DOUBLE的列的遷移精度是否符合業務預期。DTS會通過ROUND(COLUMN,PRECISION)來讀取這兩類列的值。如果沒有明確定義其精度，DTS對FLOAT的遷移精度為38位，對DOUBLE的遷移精度為308位。
-
DTS會嘗試恢複七天之內遷移失敗任務。因此，在業務切換至目標執行個體前，請務必結束或釋放該任務，或者使用revoke命令回收DTS訪問目標執行個體帳號的寫入權限。避免該任務被自動回復後，源端資料覆蓋目標執行個體的資料。
-
若RDS MySQL執行個體已開通全密態（EncDB）功能，則不支援全量資料移轉。
說明
開啟透明資料加密TDE（Transparent Data Encryption）功能的RDS MySQL執行個體支援庫表結構遷移、全量資料移轉和增量資料移轉。
-
若執行個體運行失敗，DTS技術支援人員將在8小時內嘗試恢複該執行個體。在恢複失敗執行個體的過程中，可能會對該執行個體進行重啟、調整參數等操作。
說明
在調整參數時，僅會修改DTS執行個體的參數，不會對資料庫中的參數進行修改。可能修改的參數，包括但不限於修改執行個體參數中的參數。
|
|
特殊情況
|
-
當源庫為自建MySQL時：
-
遷移時源庫進行主備切換，會導致遷移任務失敗。
-
由於DTS的延遲時間是根據遷移到目標庫最後一條資料的時間戳記和目前時間戳對比得出，源庫長時間未執行DML操作可能導致延遲資訊不準確。如果任務顯示的延遲時間過大，您可以在源庫執行一個DML操作來更新延遲資訊。
說明
如果遷移對象選擇為整庫，您還可以建立心跳錶，心跳錶每秒定期更新或者寫入資料。
-
DTS會在源庫定時執行CREATE DATABASE IF NOT EXISTS `test`命令以推進Binlog位點。
-
若源庫為Amazon Aurora MySQL或其他叢集模式的MySQL執行個體，請確保任務配置的網域名稱或IP地址及其解析結果為始終為RW（讀寫）節點地址，否則可能會導致遷移任務無法正常運行。
-
|
MySQL遷移至雲原生資料倉儲AnalyticDB MySQL版
具體注意事項及限制如下：
|
類型
|
說明
|
|
源庫限制
|
-
頻寬要求：源庫所屬的伺服器需具備足夠出口頻寬，否則將影響資料移轉速率。
-
待遷移的表需具備主鍵或唯一約束，且欄位具有唯一性，否則可能會導致目標資料庫中出現重複資料。
-
如遷移對象為表層級，且需進行編輯（如表列名映射），則單次遷移任務僅支援遷移至多1000張表。當超出數量限制，任務提交後會顯示請求報錯，此時建議您拆分待遷移的表，分批配置多個任務，或者配置整庫的遷移任務。
-
如需進行增量遷移，Binlog日誌：
-
需開啟，並且binlog_format為row、binlog_row_image為full。否則預檢查階段提示報錯，且無法成功啟動資料移轉任務。
重要
如源執行個體自建MySQL是雙主叢集（兩者互為主從），為保障DTS能擷取全部的Binlog日誌，則您需開啟參數log_slave_updates。
-
RDS MySQL執行個體的本地Binlog日誌需保留3天及以上（建議保留7天），自建MySQL資料庫的本地Binlog日誌需保留7天及以上。否則DTS可能會因無法擷取Binlog而導致任務失敗，極端情況下甚至可能會導致資料不一致或資料丟失。由於您所設定的Binlog日誌儲存時間低於DTS要求的時間而導致的問題，不在DTS的SLA保障範圍內。
說明
RDS MySQL執行個體的本地Binlog日誌保留時間長度的設定方法，請參見自動刪除本地日誌。
-
源庫的操作限制：
-
在庫表結構遷移和全量遷移階段，請勿執行庫或表結構變更的DDL操作，否則資料移轉任務會失敗。
說明
在全量遷移階段，DTS將對源庫進行查詢，這將產生中繼資料鎖，從而可能阻礙來源資料庫的DDL操作執行。
-
遷移期間，請勿執行添加註釋的DDL操作（如ALTER TABLE table_name COMMENT='表的注釋';），否則資料移轉任務會失敗。
-
若僅執行全量資料移轉，請勿向源執行個體中寫入新的資料，否則會導致源和目標資料不一致。為即時保持資料一致性，建議選擇結構遷移、全量資料移轉和增量資料移轉。
-
在遷移執行個體運行期間，不記錄Binlog的變更操作所產生的資料（例如通過物理備份功能恢複、級聯操作等產生的資料），不會被遷移到目標庫。
說明
若有該情況，您可以在業務允許的前提下，重新遷移全量資料。
-
若源庫為8.0.23及以後版本的MySQL資料庫，且待遷移的資料中包含不可見的隱藏列，則可能會因為無法擷取該列的資料而導致資料丟失。
說明
您可以使用ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;命令，將該隱藏列設定為可見。更多資訊，請參見Invisible Columns。
|
|
其他限制
|
-
暫不支援遷移首碼索引，如果源庫存在首碼索引可能會導致資料移轉失敗。
-
不支援遷移INDEX、PARTITION、VIEW、PROCEDURE、FUNCTION、TRIGGER、FK。
-
若源庫有暫存資料表模式的Online DDL變更操作（包括但不限於多表合并情境）或對唯一鍵列添加函數索引，則可能導致目標庫資料丟失或遷移執行個體運行失敗。
-
若在遷移執行個體運行時遇到主鍵或唯一鍵衝突：
-
目標庫中需存在自訂主鍵，或者在庫表列配置階段配置主鍵列，否則可能會導致資料移轉失敗。
-
由於雲原生資料倉儲AnalyticDB MySQL版本身的使用限制，當雲原生資料倉儲AnalyticDB MySQL版中的節點磁碟空間使用量超過80%，會導致DTS任務異常，產生延遲。請提前根據待遷移的對象預估所需空間，確保目的地組群具備充足的儲存空間。
-
若DTS任務運行時目標AnalyticDB MySQL版 3.0叢集處於備份中的狀態，則會導致任務失敗。
-
執行資料移轉前需評估源庫和目標庫的效能，同時建議業務低峰期執行資料移轉。否則全量資料移轉時DTS佔用源和目標庫一定讀寫資源，可能會導致資料庫的負載上升。
-
由於全量資料移轉會並發執行INSERT操作，導致目標資料庫的表產生片段，因此全量遷移完成後目標資料庫的表格儲存體空間會比源執行個體的表格儲存體空間大。
-
請確認DTS對資料類型為FLOAT或DOUBLE的列的遷移精度是否符合業務預期。DTS會通過ROUND(COLUMN,PRECISION)來讀取這兩類列的值。如果沒有明確定義其精度，DTS對FLOAT的遷移精度為38位，對DOUBLE的遷移精度為308位。
-
DTS會嘗試恢複七天之內遷移失敗任務。因此，在業務切換至目標執行個體前，請務必結束或釋放該任務，或者使用revoke命令回收DTS訪問目標執行個體帳號的寫入權限。避免該任務被自動回復後，源端資料覆蓋目標執行個體的資料。
-
若目標庫的DDL寫入失敗，DTS任務會繼續運行，您需要在任務日誌中查看執行失敗的DDL。查看任務日誌的方法，請參見查詢任務日誌。
-
若RDS MySQL執行個體已開通全密態（EncDB）功能，則不支援全量資料移轉。
說明
開啟透明資料加密TDE（Transparent Data Encryption）功能的RDS MySQL執行個體支援庫表結構遷移、全量資料移轉和增量資料移轉。
-
若執行個體運行失敗，DTS技術支援人員將在8小時內嘗試恢複該執行個體。在恢複失敗執行個體的過程中，可能會對該執行個體進行重啟、調整參數等操作。
說明
在調整參數時，僅會修改DTS執行個體的參數，不會對資料庫中的參數進行修改。可能修改的參數，包括但不限於修改執行個體參數中的參數。
|
|
特殊情況
|
-
當源庫為自建MySQL時：
-
遷移時源庫進行主備切換，會導致遷移任務失敗。
-
由於DTS的延遲時間是根據遷移到目標庫最後一條資料的時間戳記和目前時間戳對比得出，源庫長時間未執行DML操作可能導致延遲資訊不準確。如果任務顯示的延遲時間過大，您可以在源庫執行一個DML操作來更新延遲資訊。
說明
如果遷移對象選擇為整庫，您還可以建立心跳錶，心跳錶每秒定期更新或者寫入資料。
-
DTS會在源庫定時執行CREATE DATABASE IF NOT EXISTS `test`命令以推進Binlog位點。
-
若源庫為Amazon Aurora MySQL或其他叢集模式的MySQL執行個體，請確保任務配置的網域名稱或IP地址及其解析結果為始終為RW（讀寫）節點地址，否則可能會導致遷移任務無法正常運行。
-
|
MySQL遷移至自建Kafka
具體注意事項及限制如下：
|
類型
|
說明
|
|
源庫限制
|
-
頻寬要求：源庫所屬的伺服器需具備足夠的出口頻寬，否則將影響資料移轉速率。
-
待遷移的表需具備主鍵或唯一約束，且欄位具有唯一性，否則可能會導致目標資料庫中出現重複資料。
-
如遷移對象為表層級，且需進行編輯（如表列名映射），則單次遷移任務僅支援遷移至多1000張表。當超出數量限制，任務提交後會顯示請求報錯，此時建議您拆分待遷移的表，分批配置多個任務，或者配置整庫的遷移任務。
-
如需進行增量遷移，Binlog日誌：
-
需開啟，並且binlog_format為row、binlog_row_image為full。否則預檢查階段提示報錯，且無法成功啟動資料移轉任務。
重要
如源執行個體自建MySQL是雙主叢集（兩者互為主從），為保障DTS能擷取全部的Binlog日誌，則您需開啟參數log_slave_updates。
-
RDS MySQL執行個體的本地Binlog日誌需保留3天及以上（建議保留7天），自建MySQL資料庫的本地Binlog日誌需保留7天及以上。否則DTS可能會因無法擷取Binlog而導致任務失敗，極端情況下甚至可能會導致資料不一致或資料丟失。由於您所設定的Binlog日誌儲存時間低於DTS要求的時間而導致的問題，不在DTS的SLA保障範圍內。
說明
RDS MySQL執行個體的本地Binlog日誌保留時間長度的設定方法，請參見自動刪除本地日誌。
-
源庫的操作限制：
-
在遷移執行個體運行期間，不記錄Binlog的變更操作所產生的資料（例如通過物理備份功能恢複、級聯操作等產生的資料），不會被遷移到目標庫。
說明
若有該情況，您可以在業務允許的前提下，重新遷移全量資料。
-
若源庫為8.0.23及以後版本的MySQL資料庫，且待遷移的資料中包含不可見的隱藏列，則可能會因為無法擷取該列的資料而導致資料丟失。
說明
您可以使用ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;命令，將該隱藏列設定為可見。更多資訊，請參見Invisible Columns。
|
|
其他限制
|
-
遷移對象僅支援資料表。
-
不支援遷移INDEX、PARTITION、VIEW、PROCEDURE、FUNCTION、TRIGGER、FK。
-
執行資料移轉前需評估源庫和目標庫的效能，同時建議業務低峰期執行資料移轉。否則全量資料移轉時DTS佔用源和目標庫一定讀寫資源，可能會導致資料庫的負載上升。
-
由於全量資料移轉會並發執行INSERT操作，導致目標資料庫的表產生片段，因此全量遷移完成後目標資料庫的表格儲存體空間會比源執行個體的表格儲存體空間大。
-
請確認DTS對資料類型為FLOAT或DOUBLE的列的遷移精度是否符合業務預期。DTS會通過ROUND(COLUMN,PRECISION)來讀取這兩類列的值。如果沒有明確定義其精度，DTS對FLOAT的遷移精度為38位，對DOUBLE的遷移精度為308位。
-
DTS會嘗試恢複七天之內遷移失敗任務。因此，在業務切換至目標執行個體前，請務必結束或釋放該任務，或者使用revoke命令回收DTS訪問目標執行個體帳號的寫入權限。避免該任務被自動回復後，源端資料覆蓋目標執行個體的資料。
-
不允許目標庫有除DTS以外的資料寫入，否則會導致源和目標庫資料不一致。
-
在遷移期間，若目標Kafka發生了擴容或縮容，您需要重啟執行個體。
-
若RDS MySQL執行個體已開通全密態（EncDB）功能，則不支援全量資料移轉。
說明
開啟透明資料加密TDE（Transparent Data Encryption）功能的RDS MySQL執行個體支援庫表結構遷移、全量資料移轉和增量資料移轉。
-
若執行個體運行失敗，DTS技術支援人員將在8小時內嘗試恢複該執行個體。在恢複失敗執行個體的過程中，可能會對該執行個體進行重啟、調整參數等操作。
說明
在調整參數時，僅會修改DTS執行個體的參數，不會對資料庫中的參數進行修改。可能修改的參數，包括但不限於修改執行個體參數中的參數。
|
|
特殊情況
|
-
當源庫為自建MySQL時：
-
遷移時源庫進行主備切換，會導致遷移任務失敗。
-
由於DTS的延遲時間是根據遷移到目標庫最後一條資料的時間戳記和目前時間戳對比得出，源庫長時間未執行DML操作可能導致延遲資訊不準確。如果任務顯示的延遲時間過大，您可以在源庫執行一個DML操作來更新延遲資訊。
說明
如果遷移對象選擇為整庫，您還可以建立心跳錶，心跳錶每秒定期更新或者寫入資料。
-
DTS會在源庫定時執行CREATE DATABASE IF NOT EXISTS `test`命令以推進Binlog位點。
-
若源庫為Amazon Aurora MySQL或其他叢集模式的MySQL執行個體，請確保任務配置的網域名稱或IP地址及其解析結果為始終為RW（讀寫）節點地址，否則可能會導致遷移任務無法正常運行。
-
|
MySQL遷移至DataHub
具體注意事項及限制如下：
|
類型
|
說明
|
|
源庫限制
|
-
頻寬要求：源庫所屬的伺服器需具備足夠出口頻寬，否則將影響資料移轉速率。
-
待遷移的表需具備主鍵或唯一約束，且欄位具有唯一性，否則可能會導致目標資料庫中出現重複資料。
-
如遷移對象為表層級，且需進行編輯（如表列名映射），則單次遷移任務僅支援遷移至多1000張表。當超出數量限制，任務提交後會顯示請求報錯，此時建議您拆分待遷移的表，分批配置多個任務，或者配置整庫的遷移任務。
-
如需進行增量遷移，Binlog日誌：
-
需開啟，並且binlog_format為row、binlog_row_image為full。否則預檢查階段提示報錯，且無法成功啟動資料移轉任務。
重要
如源執行個體自建MySQL是雙主叢集（兩者互為主從），為保障DTS能擷取全部的Binlog日誌，則您需開啟參數log_slave_updates。
-
RDS MySQL執行個體的本地Binlog日誌需保留3天及以上（建議保留7天），自建MySQL資料庫的本地Binlog日誌需保留7天及以上。否則DTS可能會因無法擷取Binlog而導致任務失敗，極端情況下甚至可能會導致資料不一致或資料丟失。由於您所設定的Binlog日誌儲存時間低於DTS要求的時間而導致的問題，不在DTS的SLA保障範圍內。
說明
RDS MySQL執行個體的本地Binlog日誌保留時間長度的設定方法，請參見自動刪除本地日誌。
在庫表結構遷移階段，請勿執行庫或表結構變更的DDL操作，否則會導致資料移轉任務失敗。 -
在遷移執行個體運行期間，不記錄Binlog的變更操作所產生的資料（例如通過物理備份功能恢複、級聯操作等產生的資料），不會被遷移到目標庫。
說明
若有該情況，您可以在業務允許的前提下，重新遷移全量資料。
-
若源庫為8.0.23及以後版本的MySQL資料庫，且待遷移的資料中包含不可見的隱藏列，則可能會因為無法擷取該列的資料而導致資料丟失。
說明
您可以使用ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;命令，將該隱藏列設定為可見。更多資訊，請參見Invisible Columns。
|
|
其他限制
|
-
僅支援表級遷移。
-
不支援遷移INDEX、PARTITION、VIEW、PROCEDURE、FUNCTION、TRIGGER、FK。
-
目標DataHub中單個String欄位的長度最大支援2 MB。
-
請勿對源庫的遷移對象使用pt-online-schema-change等類似工具執行線上DDL變更，否則會導致遷移失敗。
-
您可以使用Data Management（Data Management）來執行線上DDL變更，請參見不鎖表結構變更。
警告
如果有除DTS外的資料寫入目標庫，請勿使用DMS執行線上DDL變更，否則可能引起目標庫資料丟失。
-
請確認DTS對資料類型為FLOAT或DOUBLE的列的遷移精度是否符合業務預期。DTS會通過ROUND(COLUMN,PRECISION)來讀取這兩類列的值。如果沒有明確定義其精度，DTS對FLOAT的遷移精度為38位，對DOUBLE的遷移精度為308位。
-
DTS會嘗試恢複七天之內遷移失敗任務。因此，在業務切換至目標執行個體前，請務必結束或釋放該任務，或者使用revoke命令回收DTS訪問目標執行個體帳號的寫入權限。避免該任務被自動回復後，源端資料覆蓋目標執行個體的資料。
-
若RDS MySQL執行個體已開通全密態（EncDB）功能，則不支援全量資料移轉。
說明
開啟透明資料加密TDE（Transparent Data Encryption）功能的RDS MySQL執行個體支援庫表結構遷移、全量資料移轉和增量資料移轉。
-
若執行個體運行失敗，DTS技術支援人員將在8小時內嘗試恢複該執行個體。在恢複失敗執行個體的過程中，可能會對該執行個體進行重啟、調整參數等操作。
說明
在調整參數時，僅會修改DTS執行個體的參數，不會對資料庫中的參數進行修改。可能修改的參數，包括但不限於修改執行個體參數中的參數。
|
|
特殊情況
|
-
當源庫為自建MySQL時：
-
遷移時源庫進行主備切換，會導致遷移任務失敗。
-
由於DTS的延遲時間是根據遷移到目標庫最後一條資料的時間戳記和目前時間戳對比得出，源庫長時間未執行DML操作可能導致延遲資訊不準確。如果任務顯示的延遲時間過大，您可以在源庫執行一個DML操作來更新延遲資訊。
說明
如果遷移對象選擇為整庫，您還可以建立心跳錶，心跳錶每秒定期更新或者寫入資料。
-
DTS會在源庫定時執行CREATE DATABASE IF NOT EXISTS `test`命令以推進Binlog位點。
-
若源庫為Amazon Aurora MySQL或其他叢集模式的MySQL執行個體，請確保任務配置的網域名稱或IP地址及其解析結果為始終為RW（讀寫）節點地址，否則可能會導致遷移任務無法正常運行。
-
|