DML replication - PolarDB - Alibaba Cloud Documentation Center

This topic describes DML replication operations on a Global Database Network (GDN).

Replication policies

DML operations trigger data changes. Data change details are recorded in binary logs as events. You can replay such events in binary logs to replicate data changes to downstream clusters. GDNs support multiple policies for DML replication (SPLIT policy is used by default) to meet the replication requirements in different scenarios.

Replication policy	Performance	Transaction consistency	Description
SPLIT (default)	High	Low	This policy is characterized by parallel replication and no guarantee of transaction integrity. It is suitable for scenarios where data dependencies are not required, as long as data consistency can be implemented. Row-level parallelism is used in replication. Data in different tables or in different primary keys is allocated to separate execution threads to achieve sufficient parallel writing.
TRANSACTION	Moderate	High	This policy is characterized by serial replication and guarantee of transaction integrity. It is suitable for scenarios where high transactional consistency is required, such as the financial sector. A recovery point objective (RPO) greater than 0 is acceptable, but transactional integrity cannot be compromised. Transaction integrity can be guaranteed only in single-stream binary log replication mode, because the multi-stream binary log mode comprises transaction integrity to improve the degree of parallelism. Parallel replication between transactions without data conflicts is not supported.
SERIAL	Moderate	Low	This policy is characterized by serial replication and no guarantee of transaction integrity. It is suitable for scenarios where low transactional consistency and high serialization are required, such as when foreign key constraints between tables or business order constraints are added. In this policy, each data change is automatically committed. This means that each transaction is standalone and no distributed transaction is triggered. Therefore, it generally provides better performance than the TRANSACTION replication policy. If each transaction in the binary log contains only one data change, the two policies produce similar performance.
MERGE	High	Low	This policy is characterized by parallel replication using techniques such as change compression and batch writing and by no guarantee of change types and change transaction integrity. It is suitable for scenarios where data dependencies are not required and where change types are insensitive, as long as data consistency can be implemented. Row-level parallelism is used in replication and data is batch processed by table to achieve full parallelism and batch writing.

Note

Data in tables without primary keys can be replicated, but duplicate data may be written.
When the TRANSACTION replication policy is used, the replication of extremely large transactions may cause a short latency on the replication link. The latency period is in proportion to the transaction size and commit time.