Source: PolarDB-X—features and constraints
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.therwise, data inconsistency may occur (for example, 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. that you use this feature. If you use this feature, DTS can guarantee only the eventual consistency of data.
- Synchronization links do not support mixed mode, which combines unit mode and copy mode.d046f6c2ofk">In unit mode, users in different regions read and write data in their local regions, and data in the local region is synchronized bidirectionally with the central data. In copy mode, cluster data is written to the central database, and then fully synchronized to each unit after the writing is complete.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.a"> instances, these two data types are allowed.
- DTS does not support synchronizing, migrating, or subscribing to stored procedures, triggers, functions, views, or events in .67382/ph_u3k_bh7_it0" docType="TOPIC" baseUrl="t1956922_v1_0_2.dita" data-latest="1" props="intl">.
- Initial schema synchronization is not supported for . You must manually create the required objects, such as databases and tables, in the destination database.">. You need to manually create the corresponding databases and tables in the destination database.
- Provision the instance with enough capacity for future business growth.ough capacity to support 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.n data-tag="ph" id="ph_l49_6sh_k7n" conref="t2067382.dita#concept_2067382/ph_u3k_bh7_it0" docType="TOPIC" baseUrl="t1956922_v1_0_2.dita" data-latest="1" props="intl">.
Database architecture constraints
- The ApsaraDB RDS for MySQL instances used by a instance cannot be used by other instances.a-latest="1" props="intl"> instance.
- 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.067382.dita#concept_2067382/ph_u3k_bh7_it0" docType="TOPIC" baseUrl="t1956922_v1_0_2.dita" data-latest="1" props="intl"> also needs to use four RDS MySQL instances with the same specifications.
- The sharding rules for the source and destination instances must be the same. Otherwise, a DTS synchronization or migration task cannot be created.rops="intl"> must be consistent. Otherwise, the DTS synchronization or migration task cannot be established.
- 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.atest="1" props="intl"> instance. Metadata tables and system tables of the instance cannot be synchronized, migrated, or subscribed.
O&M change constraints
Change type | Specific change | Impact and response |
PolarDB-X aspect | Sharding changes (such as changing sharding keys or the number of shards). | Not supported. You need to re-create the task by performing the following steps:
|
Changes in the number of storage-layer instances (such as capacity expansion or hot table migration). | ||
Storage layer aspect | Specification changes or switches at the storage-layer instance level. | Does not affect DTS tasks. |
Parameter modification. | The parameters of the source and destination databases must be consistent. Only backward-compatible parameter modifications are allowed at the storage-layer instance level. That is, new parameters do not affect the behavior and data of old parameters. Note If you are not sure, contact the database expert service group. | |
Backup and recovery policies, enabling audit, and diagnostics within storage-layer instances. | These actions are effective for the current instance and do not involve other instances that have a replication relationship. | |
DTS task aspect | DDL operations. | If you configure a DTS task from multiple RDS MySQL instances under PolarDB-X to the destination database, due to the implementation logic of MySQL, performing DDL operations may cause DTS task latency. |
DDL operations at the database or table level | Adding tables. | Not supported. Perform the following steps:
The table creation is only officially complete after all the operations above are completed. Then, the business can start writing. If synchronization is based on the table level, you need to add the new tables to the synchronization queue on the storage-layer instances of the source and destination. |
Adding fields, adding secondary indexes, deleting indexes, and modifying indexes (except for converting secondary indexes to unique indexes). |
| |
Other DDL operations except those described above. | Such DDL operations are prohibited. | |
Traffic switching Note Traffic switching refers to switching business traffic from the source database to the destination database after DTS synchronizes or migrates data from the source database to the destination database. | Normal traffic switching. | You can perform a safe traffic switching only after the latency detection feature provided by DTS shows that there is no latency. Otherwise, data quality issues will occur. |
Abnormal traffic switching that meets the Recovery Point Objective (RPO). Note RPO represents the amount of data that a business can afford to lose after recovery from a failure, expressed in time. Warning Abnormal traffic switching refers to the traffic switching operation when the source instance or the data center where the source instance is located fails. Such operations are lossy operations, which may cause data inconsistency or task failure. | In case of a failure (such as network interruption, batch equipment failures in the equipment room, or Internet data center (IDC) failure) and the DTS task has latency, if the time difference between the last data updated to the destination database and the time when the failure occurred is less than the RPO (for example, 5 minutes), you can switch traffic to give priority to business recovery. After the switch, data quality issues may occur within 5 minutes and require business developers to correct them to ensure data consistency. | |
Abnormal traffic switching that does not meet the RPO. | Large numbers of DDL operations on the source, network issues, or destination database performance issues may cause DTS task latency. If a data center failure occurs at that moment and the timestamp difference between the last data synchronized or migrated to the destination database and the failure time is greater than the RPO (for example, 5 minutes), traffic switching should be performed with great caution. We recommend that you do not perform traffic switching temporarily and wait for the data center to recover. If abnormal traffic switching is performed, data quality issues within the latency window will occur, which require business developers to correct to ensure data 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. the primary database is not updated to the secondary database in time. In this case, if the source instance performs a primary/secondary switchover, DTS uses the secondary of the source instance as the source database for data synchronization, migration, or subscription, which causes the loss of data that has not been updated to the secondary in time.
- 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.esynchronize, remigrate, or resubscribe to the data of a period before the failure occurred, to avoid data loss in the destination database. In this case, if the destination table lacks a primary key, source and destination data will be inconsistent. If the destination table has a primary key, source and destination data may not be consistent during the retry mechanism, but data will be consistent after the retry ends.
- Network issues or DDL operations can cause DTS task latency.s DDL operations that 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.ase performance, or any reason that causes table structure inconsistency may cause DTS task latency or interruption.
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.tions must be confirmed by on-site engineers to comply with the daily DDL change specifications described above.
- Do not perform DDL operations directly in program code.rations directly in program code.