由於PolarDB-X 1.0自身不提供Binlog以及其他的一些限制，在業務設計、營運變更、資料品質以及業務開發時，會受到如下規範的約束，請您在實際使用中注意。
概覽
業務設計規範
- 表都需要有主鍵，否則可能會造成資料不一致（造成目標庫有重複資料）。
- 因為PolarDB-X 1.0的GSI全域二級索引（Global Secondary Index）具有非同步特性，不推薦您使用該功能。如果您仍選擇使用該功能，DTS只能保證最終資料的一致性。
- 資料庫不支援混合模式，即unit模式和copy模式混合的同步鏈路。說明 unit模式是多地使用者分別在各自地區讀寫本地區的資料，且本地區的資料會和中心資料雙向同步。copy模式是指此叢集資料在中樞資料庫寫入，完成後全量同步到各個單元。
- 如果是使用底層MySQL進行鏈路配置，PolarDB-X 1.0間雙向同步，業務表不支援使用FLOAT、DOUBLE類型欄位，需要改為decimal類型。如果為PolarDB-X 1.0間單向同步、遷移或訂閱，則允許使用這兩種資料類型。
- DTS不支援同步、遷移或訂閱PolarDB-X 1.0中預存程序、觸發器、函數、視圖、事件等對象。
- 不支援PolarDB-X 1.0的結構初始化，需要在目標庫手動建立好對應的庫表等對象。
- PolarDB-X 1.0留夠足夠支撐業務增長的容量。
- 如PolarDB-X 1.0執行個體下掛載的MySQL版本為5.7和8.0，則不支援直接訂閱該PolarDB-X 1.0執行個體，需要對該執行個體下的多個MySQL配置單獨的資料訂閱任務來實現對PolarDB-X 1.0資料的訂閱和消費。
資料庫結構描述規範
- 一個PolarDB-X 1.0執行個體使用到的RDS MySQL執行個體，不能再被其他PolarDB-X 1.0執行個體使用。
- PolarDB-X 1.0間的同步或遷移，兩端對應的RDS MySQL執行個體需保持對等部署，比如源PolarDB-X 1.0使用了4個RDS MySQL執行個體，目標PolarDB-X 1.0也需要使用4個規格配置相同的RDS MySQL執行個體。
- 源和目標PolarDB-X 1.0的分庫分表規則需要保持一致，否則DTS同步或遷移任務無法建立。
- 只能同步、遷移或訂閱PolarDB-X 1.0執行個體的業務表，無法同步、遷移或訂閱該執行個體的中繼資料表和系統資料表。
營運變更規範
| 變更類型 | 具體變更 | 影響及應對規範 |
| PolarDB-X 1.0方面 | 分庫分表變化（如變更分庫分表鍵、或變更分庫分表數量）情境。 | 暫不支援，需按如下步驟重新建立任務：
|
| 儲存層執行個體個數發生變化情境（如擴容、熱點表遷移等）。 | ||
| 儲存層方面 | 儲存層執行個體層級的規格變更、切換等。 | 不影響DTS任務。 |
| 參數修改。 | 源庫和目標庫的參數需一致。儲存層執行個體層級參數修改只允許做向下相容的參數修改，即新參數不會影響老參數的行為和資料。 說明 如不確認需聯絡資料庫專家服務組。 | |
| 儲存層執行個體內備份恢複策略、開啟審計、診斷等。 | 對當前執行個體有效，不涉及有複製關係的其他執行個體。 | |
| DTS任務方面 | DDL操作。 | 如果是配置PolarDB-X 1.0下的多個RDS MySQL到目標庫的DTS任務，受限於MySQL的實現邏輯，執行DDL操作可能會導致DTS任務延遲。 |
| 庫表層級的DDL操作 | 新增表。 | 不支援，需要按照如下步驟操作：
|
| 增加欄位、增加二級索引、刪除索引、修改索引（二級索引改成唯一索引除外）。 |
| |
| 除上述操作以外的其他DDL操作。 | 禁止此類DDL操作。 | |
| 切流操作 說明 切流操作是指，通過DTS將資料從源庫同步或遷移至目標庫後，您將業務流量從源庫切換至目標庫。 | 正常的切流。 | DTS提供的延遲檢測功能判斷無延時後，您才能進行安全切流，否則會產生資料品質問題。 |
| 滿足復原點目標RPO（Recovery Point Objective）的異常切流。 說明 RPO代表故障恢複後業務允許丟失的資料量，可用時間表示。 警告 異常切流是指源執行個體或者源執行個體所在的資料中心發生故障時進行的切流操作。這類操作都是有損操作。 | 在出現故障（如網路中斷、機房批量裝置故障或互連網資料中心IDC故障），且DTS任務存在延遲的情況下，此時如更新至目標庫的最後一條資料的時間與故障發生時的時間之差小於RPO（如5分鐘），則可以業務優先恢複為準則切流。切流後可能有5分鐘以內的資料品質問題，需要您的業務開發配合訂正，確保資料的一致性。 | |
| 不滿足RPO的異常切流。 | 源端執行大量DDL操作、網路、目的庫效能等問題，可能會導致DTS任務存在延遲，此時如剛好遇到機房故障，且同步或遷移至目標庫的最後一條資料的時間戳記與故障發生時的時間戳記之差大於RPO（如5分鐘），那麼切流需要非常謹慎，建議您暫時不要執行切流操作，選擇等待機房恢複正常。如果遇到異常切流，會存在延時視窗內的資料品質問題，需要您的業務開發配合訂正，確保資料的一致性。 |
資料品質風險聲明
一些變更或切流操作可能會導致源庫和目標庫結構不一致等資料品質問題，具體樣本如下：
- 當源執行個體主備之間存在資料延遲時，新寫入主庫的資料未能及時更新至備庫。此時，如源執行個體進行主備切換，DTS會使用源執行個體的備庫作為來源資料庫進行資料同步、遷移或訂閱，從而導致丟失未能及時更新至備庫的部分資料。
- 在斷網、業務切流後，如DTS任務恢複正常，會自動啟動重試機制，重新同步、遷移或訂閱故障發生前一段時間的資料，以避免目標庫資料丟失。在這種情況下，如目標表缺少主鍵，會導致源目庫資料不一致；如目標表存在主鍵，則在重試機制過程中源目庫資料不一定能保持一致，但在重試結束後資料將保持一致。
- 網路問題或業務DDL，導致DTS任務延時。
- 源庫變更、目標庫效能、任何原因使表結構不一致等問題導致DTS任務延時或中斷。
阿里雲無法解決以上問題，需要您重構鏈路或者自行調整源庫和目標庫。
業務開發的資料品質工作
- 請您謹慎執行所有的DDL操作，所有的DDL操作都要經過駐場同學的確認，以遵守上述日常DDL變更規範。
- 請勿在程式碼中直接進行DDL操作。