全部產品

Data Transmission Service：遷移時源庫為PolarDB MySQL版的注意事項及限制

更新時間：Nov 20, 2025

如果遷移的源叢集為PolarDB MySQL版，您需要在配置具體的遷移任務前，參考本文的注意事項及限制，以保障資料移轉任務的正常運行。

源庫為PolarDB MySQL版的遷移方案概覽

根據如下遷移方案，查看遷移任務的注意事項及限制：

PolarDB MySQL版間的遷移
PolarDB MySQL版遷移至RDS MySQL、自建MySQL
PolarDB MySQL版遷移至PolarDB-X 2.0
PolarDB MySQL遷移至雲原生資料倉儲 AnalyticDB MySQL 版
PolarDB MySQL版遷移至自建Oracle
PolarDB MySQL版遷移至DataHub

PolarDB MySQL版間的遷移

具體注意事項及限制如下：

類型	說明
源庫限制	頻寬要求：源庫所屬的伺服器需具備足夠出口頻寬，否則將影響資料移轉速率。待遷移的表需具備主鍵或唯一約束，且欄位具有唯一性，否則可能會導致目標資料庫中出現重複資料。如遷移對象為表層級，且需進行編輯（如表列名映射），則單次遷移任務僅支援遷移至多1000張表。當超出數量限制，任務提交後會顯示請求報錯，此時建議您拆分待遷移的表，分批配置多個任務，或者配置整庫的遷移任務。如需進行增量遷移：需開啟Binlog日誌，並且需要將loose_polar_log_bin參數設定為on。否則預檢查階段提示報錯，且無法成功啟動資料移轉任務。開啟Binlog日誌和修改參數的方法，請參見開啟Binlog和修改參數值。說明 PolarDB MySQL版叢集開啟Binlog日誌會佔用一定的儲存空間，需要收取儲存費用。 PolarDB MySQL版叢集的Binlog日誌需保留3天及以上（建議保留7天），否則DTS可能會因無法擷取Binlog而導致任務失敗，極端情況下甚至可能會導致資料不一致或資料丟失。由於您所設定的Binlog日誌儲存時間低於DTS要求的時間而導致的問題，不在DTS的SLA保障範圍內。說明 PolarDB MySQL版叢集的Binlog日誌保留時間長度的設定方法，請參見修改儲存時間長度。源庫的操作限制：在庫表結構遷移和全量遷移階段，請勿執行庫或表結構變更的DDL操作，否則資料移轉任務會失敗。說明在全量遷移階段，DTS將對源庫進行查詢，這將產生中繼資料鎖，從而可能阻礙來源資料庫的DDL操作執行。如僅執行全量資料移轉，請勿向源執行個體中寫入新的資料，否則會導致源和目標資料不一致。為即時保持資料一致性，建議選擇結構遷移、全量資料移轉和增量資料移轉。
其他限制	建議源和目標PolarDB MySQL版的MySQL版本保持一致，以保障相容性。不支援遷移使用注釋文法定義的解析器（Parser）。不支援遷移源PolarDB MySQL版唯讀節點。不支援遷移源PolarDB MySQL版的OSS外表。不支援遷移INDEX、PARTITION。 DTS全量遷移階段不支援資料庫執行個體的主備切換情境。在此情境下，請及時重新設定遷移任務。若源庫有暫存資料表模式的Online DDL變更操作（包括但不限於多表合并情境），則可能導致目標庫資料丟失或遷移執行個體運行失敗。若在遷移執行個體運行時遇到主鍵或唯一鍵衝突：表結構一致的情況下，在目標庫遇到與源庫主鍵的值相同的記錄：全量期間，DTS會保留目的地組群中的該條記錄，即源庫中的該條記錄不會遷移至目標資料庫中。增量期間，DTS不會保留目的地組群中的該條記錄，即源庫中的該條記錄會覆蓋至目標資料庫中。表結構不一致的情況下，可能導致只能遷移部分列的資料或遷移失敗，請謹慎操作。若待遷移的資料中包含需要四位元組儲存的內容（例如生僻字、表情等資訊），則目標端接收資料的資料庫和表必須使用utf8mb4字元集。說明若您使用DTS遷移庫表結構，則需將目標庫中執行個體層級的參數`character_set_server`設定為utf8mb4。執行資料移轉前需評估源庫和目標庫的效能，同時建議業務低峰期執行資料移轉。否則全量資料移轉時DTS佔用源和目標庫一定讀寫資源，可能會導致資料庫的負載上升。由於全量資料移轉會並發執行INSERT操作，導致目標資料庫的表產生片段，因此全量遷移完成後目標資料庫的表格儲存體空間會比源執行個體的表格儲存體空間大。請確認DTS對資料類型為FLOAT或DOUBLE的列的遷移精度是否符合業務預期。DTS會通過`ROUND(COLUMN,PRECISION)`來讀取這兩類列的值。如果沒有明確定義其精度，DTS對FLOAT的預設遷移精度為38位，對DOUBLE的預設遷移精度為308位。 DTS會嘗試恢複七天之內遷移失敗任務。因此業務切換至目標執行個體前，請務必結束或釋放該任務，或者將DTS訪問目標執行個體帳號的寫入權限用`revoke`命令回收掉。避免該任務被自動回復後，源端資料覆蓋目標執行個體的資料。若目標庫的DDL寫入失敗，DTS任務會繼續運行，您需要在任務日誌中查看執行失敗的DDL。查看任務日誌的方法，請參見查詢任務日誌。若您需要遷移源庫中的帳號，則還需滿足相應的前提條件，並瞭解相關注意事項。更多資訊，請參見遷移資料庫帳號。若執行個體運行失敗，DTS技術支援人員將在8小時內嘗試恢複該執行個體。在恢複失敗執行個體的過程中，可能會對該執行個體進行重啟、調整參數等操作。說明在調整參數時，僅會修改DTS執行個體的參數，不會對資料庫中的參數進行修改。可能修改的參數，包括但不限於修改執行個體參數中的參數。
其他注意事項	DTS會在源庫定時執行CREATE DATABASE IF NOT EXISTS `test`命令以推進Binlog位點。

PolarDB MySQL版遷移至RDS MySQL、自建MySQL

具體注意事項及限制如下：

類型	說明
源庫限制	頻寬要求：源庫所屬的伺服器需具備足夠出口頻寬，否則將影響資料移轉速率。待遷移的表需具備主鍵或唯一約束，且欄位具有唯一性，否則可能會導致目標資料庫中出現重複資料。如遷移對象為表層級，且需進行編輯（如表列名映射），則單次遷移任務僅支援遷移至多1000張表。當超出數量限制，任務提交後會顯示請求報錯，此時建議您拆分待遷移的表，分批配置多個任務，或者配置整庫的遷移任務。如需進行增量遷移：需開啟Binlog日誌，並且需要將loose_polar_log_bin參數設定為on。否則預檢查階段提示報錯，且無法成功啟動資料移轉任務。開啟Binlog日誌和修改參數的方法，請參見開啟Binlog和修改參數值。說明 PolarDB MySQL版叢集開啟Binlog日誌會佔用一定的儲存空間，需要收取儲存費用。 PolarDB MySQL版叢集的Binlog日誌需保留3天及以上（建議保留7天），否則DTS可能會因無法擷取Binlog而導致任務失敗，極端情況下甚至可能會導致資料不一致或資料丟失。由於您所設定的Binlog日誌儲存時間低於DTS要求的時間而導致的問題，不在DTS的SLA保障範圍內。說明 PolarDB MySQL版叢集的Binlog日誌保留時間長度的設定方法，請參見修改儲存時間長度。源庫的操作限制：在庫表結構遷移和全量遷移階段，請勿執行庫或表結構變更的DDL操作，否則資料移轉任務會失敗。說明在全量遷移階段，DTS將對源庫進行查詢，這將產生中繼資料鎖，從而可能阻礙來源資料庫的DDL操作執行。如僅執行全量資料移轉，請勿向源執行個體中寫入新的資料，否則會導致源和目標資料不一致。為即時保持資料一致性，建議選擇結構遷移、全量資料移轉和增量資料移轉。
注意事項	不支援遷移源PolarDB MySQL版唯讀節點。不支援遷移源PolarDB MySQL版的OSS外表。不支援遷移INDEX、PARTITION。不支援遷移使用注釋文法定義的解析器（Parser）。 DTS全量遷移階段不支援資料庫執行個體的主備切換情境。在此情境下，請及時重新設定遷移任務。若源庫有暫存資料表模式的Online DDL變更操作（包括但不限於多表合并情境），則可能導致目標庫資料丟失或遷移執行個體運行失敗。若在遷移執行個體運行時遇到主鍵或唯一鍵衝突：表結構一致的情況下，在目標庫遇到與源庫主鍵的值相同的記錄：全量期間，DTS會保留目的地組群中的該條記錄，即源庫中的該條記錄不會遷移至目標資料庫中。增量期間，DTS不會保留目的地組群中的該條記錄，即源庫中的該條記錄會覆蓋至目標資料庫中。表結構不一致的情況下，可能導致只能遷移部分列的資料或遷移失敗，請謹慎操作。若待遷移的資料中包含需要四位元組儲存的內容（例如生僻字、表情等資訊），則目標端接收資料的資料庫和表必須使用utf8mb4字元集。說明若您使用DTS遷移庫表結構，則需將目標庫中執行個體層級的參數`character_set_server`設定為utf8mb4。執行資料移轉前需評估源庫和目標庫的效能，同時建議業務低峰期執行資料移轉。否則全量資料移轉時DTS佔用源和目標庫一定讀寫資源，可能會導致資料庫的負載上升。由於全量資料移轉會並發執行INSERT操作，導致目標資料庫的表產生片段，因此全量遷移完成後目標資料庫的表格儲存體空間會比源執行個體的表格儲存體空間大。請確認DTS對資料類型為FLOAT或DOUBLE的列的遷移精度是否符合業務預期。DTS會通過`ROUND(COLUMN,PRECISION)`來讀取這兩類列的值。如果沒有明確定義其精度，DTS對FLOAT的預設遷移精度為38位，對DOUBLE的預設遷移精度為308位。 DTS會嘗試恢複七天之內遷移失敗任務。因此業務切換至目標執行個體前，請務必結束或釋放該任務，或者將DTS訪問目標執行個體帳號的寫入權限用`revoke`命令回收掉。避免該任務被自動回復後，源端資料覆蓋目標執行個體的資料。 DTS會在源庫定時執行CREATE DATABASE IF NOT EXISTS `test`命令以推進Binlog位點。若目標庫的DDL寫入失敗，DTS任務會繼續運行，您需要在任務日誌中查看執行失敗的DDL。查看任務日誌的方法，請參見查詢任務日誌。若您將列名僅大小寫不同的欄位寫入到目標MySQL資料庫的同一個表中，可能會因為MySQL資料庫列名大小寫不敏感，導致遷移結果不符合預期。在資料移轉完成後（執行個體的運行狀態為已完成），建議使用`analyze table <表名>`命令以確認資料均已寫入目標表。例如，在目標MySQL資料庫觸發HA切換機制後，可能會導致資料唯寫到了記憶體，從而造成資料丟失。若執行個體運行失敗，DTS技術支援人員將在8小時內嘗試恢複該執行個體。在恢複失敗執行個體的過程中，可能會對該執行個體進行重啟、調整參數等操作。說明在調整參數時，僅會修改DTS執行個體的參數，不會對資料庫中的參數進行修改。可能修改的參數，包括但不限於修改執行個體參數中的參數。
特殊情況	當目標庫為RDS MySQL時，DTS會自動在RDS MySQL中建立資料庫，如果待遷移的資料庫名稱不符合RDS MySQL的定義規範，您需要在配置遷移任務之前在RDS MySQL中建立資料庫。相關操作，請參見管理資料庫。

PolarDB MySQL版遷移至PolarDB-X 2.0

具體注意事項及限制如下：

類型	說明
源庫限制	頻寬要求：源庫所屬的伺服器需具備足夠出口頻寬，否則將影響資料移轉速率。待遷移的表需具備主鍵或唯一約束，且欄位具有唯一性，否則可能會導致目標資料庫中出現重複資料。如遷移對象為表層級，且需進行編輯（如表列名映射），則單次遷移任務僅支援遷移至多1000張表。當超出數量限制，任務提交後會顯示請求報錯，此時建議您拆分待遷移的表，分批配置多個任務，或者配置整庫的遷移任務。如需進行增量遷移：需開啟Binlog日誌，並且需要將loose_polar_log_bin參數設定為on。否則預檢查階段提示報錯，且無法成功啟動資料移轉任務。開啟Binlog日誌和修改參數的方法，請參見開啟Binlog和修改參數值。說明 PolarDB MySQL版叢集開啟Binlog日誌會佔用一定的儲存空間，需要收取儲存費用。 PolarDB MySQL版叢集的Binlog日誌需保留3天及以上（建議保留7天），否則DTS可能會因無法擷取Binlog而導致任務失敗，極端情況下甚至可能會導致資料不一致或資料丟失。由於您所設定的Binlog日誌儲存時間低於DTS要求的時間而導致的問題，不在DTS的SLA保障範圍內。說明 PolarDB MySQL版叢集的Binlog日誌保留時間長度的設定方法，請參見修改儲存時間長度。源庫的操作限制：在全量遷移階段，請勿執行庫或表結構變更的DDL操作，否則資料移轉任務會失敗。說明在全量遷移階段，DTS將對源庫進行查詢，這將產生中繼資料鎖，從而可能阻礙來源資料庫的DDL操作執行。如僅執行全量資料移轉，請勿向源執行個體中寫入新的資料，否則會導致源和目標資料不一致。為即時保持資料一致性，建議選擇全量資料移轉和增量資料移轉。暫不支援增量遷移DDL操作，否則資料移轉任務會失敗。如需進行DDL操作，建議您先在目標庫手動執行後，在源庫重複相應的DDL操作。
注意事項	若源庫有暫存資料表模式的Online DDL變更操作（包括但不限於多表合并情境），則可能導致目標庫資料丟失或遷移執行個體運行失敗。若在遷移執行個體運行時遇到主鍵或唯一鍵衝突：表結構一致的情況下，在目標庫遇到與源庫主鍵的值相同的記錄：全量期間，DTS會保留目的地組群中的該條記錄，即源庫中的該條記錄不會遷移至目標資料庫中。增量期間，DTS不會保留目的地組群中的該條記錄，即源庫中的該條記錄會覆蓋至目標資料庫中。表結構不一致的情況下，可能導致只能遷移部分列的資料或遷移失敗，請謹慎操作。不支援遷移源PolarDB MySQL版唯讀節點。不支援遷移源PolarDB MySQL版的OSS外表。 DTS全量遷移階段不支援資料庫執行個體的主備切換情境。在此情境下，請及時重新設定遷移任務。執行資料移轉前需評估源庫和目標庫的效能，同時建議業務低峰期執行資料移轉。否則全量資料移轉時DTS佔用源和目標庫一定讀寫資源，可能會導致資料庫的負載上升。由於全量資料移轉會並發執行INSERT操作，導致目標資料庫的表產生片段，因此全量遷移完成後目標資料庫的表格儲存體空間會比源執行個體的表格儲存體空間大。請確認DTS對資料類型為FLOAT或DOUBLE的列的遷移精度是否符合業務預期。DTS會通過`ROUND(COLUMN,PRECISION)`來讀取這兩類列的值。如果沒有明確定義其精度，DTS對FLOAT的預設遷移精度為38位，對DOUBLE的預設遷移精度為308位。 DTS會嘗試恢複七天之內遷移失敗任務。因此業務切換至目標執行個體前，請務必結束或釋放該任務，或者將DTS訪問目標執行個體帳號的寫入權限用`revoke`命令回收掉。避免該任務被自動回復後，源端資料覆蓋目標執行個體的資料。 DTS會在源庫定時執行CREATE DATABASE IF NOT EXISTS `test`命令以推進Binlog位點。若執行個體運行失敗，DTS技術支援人員將在8小時內嘗試恢複該執行個體。在恢複失敗執行個體的過程中，可能會對該執行個體進行重啟、調整參數等操作。說明在調整參數時，僅會修改DTS執行個體的參數，不會對資料庫中的參數進行修改。可能修改的參數，包括但不限於修改執行個體參數中的參數。

PolarDB MySQL版遷移至AnalyticDB for MySQL

具體注意事項及限制如下：

類型	說明
源庫限制	頻寬要求：源庫所屬的伺服器需具備足夠出口頻寬，否則將影響資料移轉速率。待遷移的表需具備主鍵或唯一約束，且欄位具有唯一性，否則可能會導致目標資料庫中出現重複資料。如遷移對象為表層級，且需進行編輯（如表列名映射），則單次遷移任務僅支援遷移至多1000張表。當超出數量限制，任務提交後會顯示請求報錯，此時建議您拆分待遷移的表，分批配置多個任務，或者配置整庫的遷移任務。如需進行增量遷移：需開啟Binlog日誌，並且需要將loose_polar_log_bin參數設定為on。否則預檢查階段提示報錯，且無法成功啟動資料移轉任務。開啟Binlog日誌和修改參數的方法，請參見開啟Binlog和修改參數值。說明 PolarDB MySQL版叢集開啟Binlog日誌會佔用一定的儲存空間，需要收取儲存費用。 PolarDB MySQL版叢集的Binlog日誌需保留3天及以上（建議保留7天），否則DTS可能會因無法擷取Binlog而導致任務失敗，極端情況下甚至可能會導致資料不一致或資料丟失。由於您所設定的Binlog日誌儲存時間低於DTS要求的時間而導致的問題，不在DTS的SLA保障範圍內。說明 PolarDB MySQL版叢集的Binlog日誌保留時間長度的設定方法，請參見修改儲存時間長度。源庫的操作限制：在庫表結構遷移和全量遷移階段，請勿執行庫或表結構變更的DDL操作，否則資料移轉任務會失敗。說明在全量遷移階段，DTS將對源庫進行查詢，這將產生中繼資料鎖，從而可能阻礙來源資料庫的DDL操作執行。遷移期間，請勿執行修改主鍵和給表添加註釋的DDL操作（如`ALTER TABLE table_name COMMENT='表的注釋';`），否則資料移轉任務會失敗。如僅執行全量資料移轉，請勿向源執行個體中寫入新的資料，否則會導致源和目標資料不一致。為即時保持資料一致性，建議選擇結構遷移、全量資料移轉和增量資料移轉。
注意事項	暫不支援遷移首碼索引，如果源庫存在首碼索引可能會導致資料移轉失敗。若源庫有暫存資料表模式的Online DDL變更操作（包括但不限於多表合并情境），則可能導致目標庫資料丟失或遷移執行個體運行失敗。若在遷移執行個體運行時遇到主鍵或唯一鍵衝突：表結構一致的情況下，在目標庫遇到與源庫主鍵的值相同的記錄：全量期間，DTS會保留目的地組群中的該條記錄，即源庫中的該條記錄不會遷移至目標資料庫中。增量期間，DTS不會保留目的地組群中的該條記錄，即源庫中的該條記錄會覆蓋至目標資料庫中。表結構不一致的情況下，可能導致只能遷移部分列的資料或遷移失敗，請謹慎操作。目標庫中需存在自訂主鍵，或者在庫表列配置階段配置主鍵列，否則可能會導致資料移轉失敗。不支援遷移源PolarDB MySQL版唯讀節點。不支援遷移源PolarDB MySQL版的OSS外表。不支援遷移INDEX、PARTITION、VIEW、PROCEDURE、FUNCTION、TRIGGER、FK。 DTS全量遷移階段不支援資料庫執行個體的主備切換情境。在此情境下，請及時重新設定遷移任務。由於雲原生資料倉儲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會嘗試恢複七天之內遷移失敗任務。因此業務切換至目標執行個體前，請務必結束或釋放該任務，或者將DTS訪問目標執行個體帳號的寫入權限用`revoke`命令回收掉。避免該任務被自動回復後，源端資料覆蓋目標執行個體的資料。 DTS會在源庫定時執行CREATE DATABASE IF NOT EXISTS `test`命令以推進Binlog位點。若目標庫的DDL寫入失敗，DTS任務會繼續運行，您需要在任務日誌中查看執行失敗的DDL。查看任務日誌的方法，請參見查詢任務日誌。若執行個體運行失敗，DTS技術支援人員將在8小時內嘗試恢複該執行個體。在恢複失敗執行個體的過程中，可能會對該執行個體進行重啟、調整參數等操作。說明在調整參數時，僅會修改DTS執行個體的參數，不會對資料庫中的參數進行修改。可能修改的參數，包括但不限於修改執行個體參數中的參數。

PolarDB MySQL版遷移至自建Oracle

具體注意事項及限制如下：

類型	說明
源庫限制	頻寬要求：源庫所屬的伺服器需具備足夠出口頻寬，否則將影響資料移轉速率。待遷移的表需具備主鍵或唯一約束，且欄位具有唯一性，否則可能會導致目標資料庫中出現重複資料。如遷移對象為表層級，且需進行編輯（如表列名映射），則單次遷移任務僅支援遷移至多1000張表。當超出數量限制，任務提交後會顯示請求報錯，此時建議您拆分待遷移的表，分批配置多個任務，或者配置整庫的遷移任務。如需進行增量遷移：需開啟Binlog日誌，並且需要將loose_polar_log_bin參數設定為on。否則預檢查階段提示報錯，且無法成功啟動資料移轉任務。開啟Binlog日誌和修改參數的方法，請參見開啟Binlog和修改參數值。說明 PolarDB MySQL版叢集開啟Binlog日誌會佔用一定的儲存空間，需要收取儲存費用。 PolarDB MySQL版叢集的Binlog日誌需保留3天及以上（建議保留7天），否則DTS可能會因無法擷取Binlog而導致任務失敗，極端情況下甚至可能會導致資料不一致或資料丟失。由於您所設定的Binlog日誌儲存時間低於DTS要求的時間而導致的問題，不在DTS的SLA保障範圍內。說明 PolarDB MySQL版叢集的Binlog日誌保留時間長度的設定方法，請參見修改儲存時間長度。源庫的操作限制：在庫表結構遷移和全量遷移階段，請勿執行庫或表結構變更的DDL操作，否則資料移轉任務會失敗。說明在全量遷移階段，DTS將對源庫進行查詢，這將產生中繼資料鎖，從而可能阻礙來源資料庫的DDL操作執行。如僅執行全量資料移轉，請勿向源執行個體中寫入新的資料，否則會導致源和目標資料不一致。為即時保持資料一致性，建議選擇結構遷移、全量資料移轉和增量資料移轉。
注意事項	不支援遷移源PolarDB MySQL版唯讀節點。不支援遷移源PolarDB MySQL版的OSS外表。 DTS全量遷移階段不支援資料庫執行個體的主備切換情境。在此情境下，請及時重新設定遷移任務。若源庫有暫存資料表模式的Online DDL變更操作（包括但不限於多表合并情境），則可能導致目標庫資料丟失或遷移執行個體運行失敗。若在遷移執行個體運行時遇到主鍵或唯一鍵衝突：表結構一致的情況下，在目標庫遇到與源庫主鍵的值相同的記錄：全量期間，DTS會保留目的地組群中的該條記錄，即源庫中的該條記錄不會遷移至目標資料庫中。增量期間，DTS不會保留目的地組群中的該條記錄，即源庫中的該條記錄會覆蓋至目標資料庫中。表結構不一致的情況下，可能導致只能遷移部分列的資料或遷移失敗，請謹慎操作。執行資料移轉前需評估源庫和目標庫的效能，同時建議業務低峰期執行資料移轉。否則全量資料移轉時DTS佔用源和目標庫一定讀寫資源，可能會導致資料庫的負載上升。由於全量資料移轉會並發執行INSERT操作，導致目標資料庫的表產生片段，因此全量遷移完成後目標資料庫的表格儲存體空間會比源執行個體的表格儲存體空間大。請確認DTS對資料類型為FLOAT或DOUBLE的列的遷移精度是否符合業務預期。DTS會通過`ROUND(COLUMN,PRECISION)`來讀取這兩類列的值。如果沒有明確定義其精度，DTS對FLOAT的預設遷移精度為38位，對DOUBLE的預設遷移精度為308位。 DTS會嘗試恢複七天之內遷移失敗任務。因此業務切換至目標執行個體前，請務必結束或釋放該任務，或者將DTS訪問目標執行個體帳號的寫入權限用`revoke`命令回收掉。避免該任務被自動回復後，源端資料覆蓋目標執行個體的資料。 DTS會在源庫定時執行CREATE DATABASE IF NOT EXISTS `test`命令以推進Binlog位點。若執行個體運行失敗，DTS技術支援人員將在8小時內嘗試恢複該執行個體。在恢複失敗執行個體的過程中，可能會對該執行個體進行重啟、調整參數等操作。說明在調整參數時，僅會修改DTS執行個體的參數，不會對資料庫中的參數進行修改。可能修改的參數，包括但不限於修改執行個體參數中的參數。
特殊情況	如自建Oracle為RAC結構，且需接入阿里雲VPC，為保證DTS任務成功運行，您需要將Oracle RAC的SCAN IP和每個節點的VIP均接入至阿里雲VPC，並且配置路由。具體步驟，請參見本地IDC接入至阿里雲方案概覽、通過VPN網關實現本地IDC與DTS雲端服務互連。重要在DTS控制台上配置源Oracle資料庫資訊時，在資料庫地址或者IP地址只需輸入Oracle RAC的SCAN IP。

PolarDB MySQL版遷移至DataHub

具體注意事項及限制如下：

類型	說明
源庫限制	待遷移的表需具備主鍵或唯一約束，且欄位具有唯一性，否則可能會導致目標資料庫中出現重複資料。如遷移對象為表層級，且需進行編輯（如表列名映射），則單次遷移任務僅支援遷移至多1000張表。當超出數量限制，任務提交後會顯示請求報錯，此時建議您拆分待遷移的表，分批配置多個任務，或者配置整庫的遷移任務。如需進行增量遷移：需開啟Binlog日誌，並且需要將loose_polar_log_bin參數設定為on。否則預檢查階段提示報錯，且無法成功啟動資料移轉任務。開啟Binlog日誌和修改參數的方法，請參見開啟Binlog和修改參數值。說明 PolarDB MySQL版叢集開啟Binlog日誌會佔用一定的儲存空間，需要收取儲存費用。 PolarDB MySQL版叢集的Binlog日誌需保留3天及以上（建議保留7天），否則DTS可能會因無法擷取Binlog而導致任務失敗，極端情況下甚至可能會導致資料不一致或資料丟失。由於您所設定的Binlog日誌儲存時間低於DTS要求的時間而導致的問題，不在DTS的SLA保障範圍內。說明 PolarDB MySQL版叢集的Binlog日誌保留時間長度的設定方法，請參見修改儲存時間長度。源庫的操作限制：在庫表結構遷移階段，請勿執行庫或表結構變更的DDL操作，否則資料移轉任務會失敗。
其他限制	不支援全量資料初始化，即DTS不會將源PolarDB MySQL版叢集中遷移對象的存量資料移轉至目標DataHub執行個體。僅支援表層級的資料移轉。不支援遷移源PolarDB MySQL版唯讀節點。不支援遷移源PolarDB MySQL版的OSS外表。 DTS全量遷移階段不支援資料庫執行個體的主備切換情境。在此情境下，請及時重新設定遷移任務。請確認DTS對資料類型為FLOAT或DOUBLE的列的遷移精度是否符合業務預期。DTS會通過`ROUND(COLUMN,PRECISION)`來讀取這兩類列的值。如果沒有明確定義其精度，DTS對FLOAT的預設遷移精度為38位，對DOUBLE的預設遷移精度為308位。 DTS會嘗試恢複七天之內遷移失敗任務。因此業務切換至目標執行個體前，請務必結束或釋放該任務，或者將DTS訪問目標執行個體帳號的寫入權限用`revoke`命令回收掉。避免該任務被自動回復後，源端資料覆蓋目標執行個體的資料。若執行個體運行失敗，DTS技術支援人員將在8小時內嘗試恢複該執行個體。在恢複失敗執行個體的過程中，可能會對該執行個體進行重啟、調整參數等操作。說明在調整參數時，僅會修改DTS執行個體的參數，不會對資料庫中的參數進行修改。可能修改的參數，包括但不限於修改執行個體參數中的參數。
其他注意事項	DTS會在源庫定時執行CREATE DATABASE IF NOT EXISTS `test`命令以推進Binlog位點。