配置以PolarDB-X為源的DTS同步或遷移任務的推薦方案-Data Transmission Service-阿里雲

DTS支援將源PolarDB-X 1.0執行個體同步或遷移至目標庫。但是由於直接使用PolarDB-X 1.0作為源執行個體配置DTS任務，當該執行個體下掛載的RDS MySQL數量超過2個時，可能會產生效能瓶頸，穩定性風險，最終可能會對業務造成影響。為了更好保障任務的效能和穩定性，DTS建議您在配置時，根據PolarDB-X 1.0下掛載的RDS MySQL執行個體，分別配置DTS任務。

前提條件

您已閱讀源為PolarDB-X的功能規格和約束說明，已確保遵循相關規範，瞭解注意事項。

任務配置方案

方案	配置方式	特點總結
方案一	針對PolarDB-X 1.0下的多個RDS MySQL執行個體，配置多個同步或遷移至目標執行個體的DTS任務，並且在配置過程中，需將多個RDS MySQL的資料庫表名都映射成目標執行個體的庫表名。該方案相比於直接配置PolarDB-X 1.0至目標執行個體的同步或遷移任務，更能保障效能和穩定性。重要該方案僅支援表層級同步或遷移。	推薦您使用方式情節一，其在效能、穩定性方面均優於方案二，且對PolarDB-X 1.0下掛載的RDS MySQL數量沒有限制。
方案二	直接使用PolarDB-X 1.0作為源執行個體配置同步或遷移至目標執行個體任務，當該執行個體下掛載的RDS MySQL執行個體數量超過2個後，可能會對DTS任務的穩定性、操作性產生較大影響，嚴重時甚至將影響業務。	使用方式情節二時，如源PolarDB-X 1.0下掛載的RDS MySQL執行個體超過2個時，DTS任務可能會有效能和穩定性風險。

方案對比

對比項	方案一	方案二
效能	拆分成多個DTS任務，效能成倍增長，可承載大規模的PolarDB-X 1.0資料寫入，	僅配置一個以PolarDB-X 1.0為源的DTS任務，當業務系統寫入源執行個體資料量較大時，會存在效能瓶頸。
穩定性	穩定性較強。配置PolarDB-X 1.0下多個RDS MySQL至目標庫的DTS任務，如其中一個DTS任務發生故障，則不影響其他DTS任務的運行，且只需恢複發生故障的DTS任務即可。	穩定性一般。僅配置一個以PolarDB-X 1.0為源的DTS任務，如該DTS任務發生故障，則整個DTS任務會失敗。
易用性	需配置多次，相對較繁瑣。需要拆分成獨立的任務，且每次配置均需做庫表名映射，將源執行個體多個RDS MySQL的庫表名映射成目標執行個體中庫表的名稱，如源執行個體中RDS MySQL執行個體的數量和庫表數量較多，則需配置多次的映射。	配置方便，僅需配置一個PolarDB-X 1.0為源的DTS任務。
資源佔用	拆分成n個獨立的DTS任務，消耗n個DTS執行個體。	消耗1個DTS執行個體。

兩種方案如何?DDL同步或增量遷移

目前PolarDB-X 1.0為源的同步或遷移任務，暫不支援同步或增量遷移DDL操作，如源PolarDB-X 1.0在同步或遷移時執行DDL操作，為避免資料寫入目標端失敗，一般解決方案如下：

釋放DTS任務。
清空目標庫。
重新設定任務。

在PolarDB-X 1.0為源的部分同步或遷移情境中，支援在保留DTS任務的同時，實現同步或增量遷移DDL操作，具體情境及對應的操作，如下所示：

情境	操作
使用方式情節一，僅支援表層級同步。	支援通過修改同步對象來實現加表的操作。目前僅PolarDB-X 1.0間的同步，支援加列、減列的操作，且需按如下操作執行：修改同步對象，使其包含或刪除列。先在目標庫手動進行加列或減列，然後在源端執行對應的加列或減列操作。當目標庫已經存在這個列時，則DTS會忽略這個報錯，且不會顯示寫入失敗。
使用方式情節二，且同步或遷移對象為整庫。	僅支援加表的操作，且需先在目標庫手動加上新表，然後在源端執行加表的操作。不支援加列、減列的操作。警告在源PolarDB分布式版執行加列操作，可能會導致底層多個物理表不一致，有的缺少該列，有的包含該列。DTS在拼裝的SQL語句，可能會找不到該列，或者丟失該列的資料，從而導致任務失敗或資料不一致。
使用方式情節二，且同步對象為非整庫。	僅支援加表的操作，且需按如下操作執行：修改同步對象，使其包含該新表。先在目標庫手動加上新表，然後在源端執行加表的操作。不支援加列、減列的操作。