does not provide binary logging and has other limitations. Review the following constraints on service design, O&M changes, data quality, and application development before you begin.
Overview
Business Design Specifications
- All tables must have primary keys. Otherwise, data inconsistency may occur and cause duplicate data in the destination database.
- The Global Secondary Index (GSI) of PolarDB distributed version is asynchronous and is not recommended. If you use GSI, DTS can only guarantee eventual data consistency.
- Synchronization links do not support mixed mode, which combines unit mode and copy mode.Note In unit mode, users in different regions read from and write to data in their local regions. This local data is then synchronized with the central data. In copy mode, data for the cluster is written to the central database and then fully synchronized to each unit.
- If you configure a two-way synchronization link between instances that use underlying MySQL databases, business tables cannot use the FLOAT or DOUBLE data types. You must change these types to DECIMAL. For one-way synchronization, migration, or change tracking tasks between instances, these two data types are allowed.
- DTS does not support synchronizing, migrating, or subscribing to stored procedures, triggers, functions, views, or events in .
- Initial schema synchronization is not supported for . You must manually create the required objects, such as databases and tables, in the destination database.
- Provision the instance with enough capacity for future business growth.
- If a instance has both MySQL 5.7 and MySQL 8.0 databases attached, you cannot directly subscribe to that instance. You must configure a separate change tracking task for each MySQL database to subscribe to and consume data from the instance.
Database architecture constraints
- The ApsaraDB RDS for MySQL instances used by a instance cannot be used by other instances.
- PolarDB Distributed Edition instances, the source and destination RDS for MySQL instances must have a peer deployment. For example, if the source PolarDB Distributed Edition instance uses four RDS for MySQL instances, the destination PolarDB Distributed Edition instance must also use four RDS for MySQL instances with identical specifications.
- The sharding rules for the source and destination instances must be the same. Otherwise, a DTS synchronization or migration task cannot be created.
- You can synchronize, migrate, or subscribe to only the business tables in a instance. You cannot synchronize, migrate, or subscribe to the metadata or system tables of the instance.
O&M change constraints
| Change type | Specific change | Impact and handling |
| PolarDB Distributed Edition | Changes to sharding, such as changing sharding keys or the number of shards. | Not supported. Recreate the task by following these steps:
|
| Changes to the number of storage layer instances, such as scaling out or migrating hot spot tables. | ||
| Storage layer | Specification changes or switches for storage layer instances. | Does not affect the DTS task. |
| Parameter modifications. | The parameters of the source and destination databases must be consistent. For instance-level parameter modifications in the storage layer, only backward-compatible changes are allowed. The new parameters must not affect the behavior or data of the old parameters. Note If you are unsure, contact the Database Expert Service group. |
|
| Backup and recovery policies, enabling auditing, diagnostics, and other settings within a storage layer instance. | Effective for the current instance. Does not affect other instances in the replication relationship. | |
| DTS task | DDL operations. | If you configure DTS tasks for multiple RDS for MySQL instances of a instance to a destination database, DDL operations may cause task latency because of limitations in the implementation of MySQL. |
| Database-level and table-level DDL operations | Adding a new table. | Not supported. Perform the following steps:
|
| Adding fields, adding secondary indexes, deleting indexes, and modifying indexes (except for changing a secondary index to a unique index). |
|
|
| Other DDL operations not listed above. | These DDL operations are prohibited. | |
| Switchover operation Note A switchover operation is when you switch your service traffic from the source database to the destination database after the data has been synchronized or migrated using DTS. |
Normal switchover. | Perform a safe switchover only after DTS latency detection confirms zero delay. Otherwise, data quality issues may occur. |
| Abnormal switchover that meets the recovery point objective (RPO). Note RPO represents the maximum amount of data, measured in time, that your service can tolerate losing after a fault recovery. Warning An abnormal switchover is a switchover performed when the source instance or its data center fails. This type of operation is lossy. |
If a failure occurs (such as a network interruption, batch device failure, or an Internet data center (IDC) failure) and the DTS task has latency, you can perform the switchover to prioritize business recovery. This is allowed if the time difference between the last data entry written to the destination database and the failure is less than the RPO (for example, 5 minutes). After the switchover, data quality issues may exist for data within the last 5 minutes. Your developers must correct the data to ensure consistency. | |
| Abnormal switchover that does not meet the RPO. | Issues such as numerous DDL operations on the source, network problems, or poor destination database performance can cause DTS task latency. If a data center fails during this time and the time difference between the last data entry written to the destination database and the failure exceeds the RPO (for example, 5 minutes), do not perform the switchover. Wait for the data center to recover. If you perform an abnormal switchover, data quality issues exist for data within the latency window. Your developers must correct the data to ensure consistency. |
Data quality risk disclaimer
Certain changes or switchover operations can cause data quality issues, such as data inconsistency between the source and destination databases.
- If data latency exists between the primary and secondary databases of the source instance, data written to the primary database is not immediately replicated to the secondary database. If a primary/secondary switchover occurs, DTS uses the new primary database (the former secondary database) as the data source. Any data not yet replicated to the secondary database before the switchover is lost.
- If a DTS task resumes after a network failure or service switchover, it automatically retries and re-synchronizes data generated before the failure to prevent data loss. In this case, if a destination table does not have a primary key, data inconsistency occurs between the source and destination databases. If a destination table has a primary key, data may be temporarily inconsistent during the retry but becomes consistent after the retry completes.
- Network issues or DDL operations can cause DTS task latency.
- Changes to the source database, poor performance of the destination database, or table schema inconsistencies can delay or interrupt the DTS task.
Alibaba Cloud is not responsible for resolving these issues. You may need to recreate the DTS task or adjust the source and destination databases.
Data quality for development
- Perform all DDL operations with caution. All DDL operations must be reviewed to ensure compliance with the preceding DDL change guidelines.
- Do not perform DDL operations directly in program code.
该文章对您有帮助吗？