Database instance replication refers to the process of synchronizing data by configuring one or more backup databases for a server, distributing PostgreSQL data across multiple systems. TencentDB for PostgreSQL supports the following two data replication methods:
Async replication
TencentDB for PostgreSQL async replication adopts a one-primary-one-replica architecture.
After receiving a data update (including INSERT, UPDATE and DELETE operations) request from an application, the source performs the update operation. When the update is completed, the source immediately responds to the application and replicates the data to the replica.
During the data update process, the source does not need to wait for the replica's response. Therefore, database instances with async replication usually have higher performance (for specific performance, see Test Results). The unavailability of the replica does not affect the source's service provision. However, since the data is not synchronized to the replica in real-time, and if a switch occurs after the source fails when there is a delay in the replica, there is a small probability that data inconsistency may occur.
Note:
TencentDB for PostgreSQL uses async replication as the default data replication method.
Semi-sync replication
TencentDB for PostgreSQL semi-sync replication adopts a one-primary-one-replica architecture.
Upon receiving a data update request (including INSERT, UPDATE, and DELETE operations) from an application, the source immediately replicates the data to the replica after performing the update operation. The replica, after receiving the data and writing it to the WAL (without executing), returns a success message to the source. The source must receive this success message from the replica before it can respond to the application.
In the event of a replication exception (such as the replica node being unavailable or a network issue affecting data replication), the primary node will temporarily pause (approximately 10 seconds by default in PostgreSQL) its response to the application and downgrade the replication mode to async replication. Once data replication returns to normal, it will resume semi-sync replication.
Degradation Description
Degradation of Faults
If the current PostgreSQL primary-standby replication mode is semi-sync, when a replication exception occurs (such as the replica node being unavailable or a network issue), the primary node will temporarily pause its response to the application (approximately 10 seconds by default in TencentDB for PostgreSQL) and downgrade the replication mode to async to ensure system availability. Once the high-availability system detects that replication has returned to normal, it will restore the primary-standby replication mode to semi-sync replication.
Note:
Degradation to high availability is the default behavior for TencentDB for PostgreSQL. To ensure system high availability, the option to modify this setting is not currently available.
Latency degradation
If you have special requirements, you can enable delay degradation under semi-sync replication. After enabling delay degradation, the TencentDB for PostgreSQL high-availability system will judge the primary-standby replication delay based on the conditions you set. If the delay exceeds the set limit, semi-sync will degrade to async. It is recommended to enable this feature only for businesses that are extremely sensitive to delay.
Degradation conditions are based on the size or time of primary-replica synchronization. Relevant monitoring metrics include replica WAL flush lag (in bytes) and replica WAL flush time lag (in seconds). For more information, refer to Primary-Replica Latency Monitoring Metrics.
Failover Description
When the primary-replica replication mode of an instance is set to async replication or semi-sync replication degraded to async replication, a primary-replica switch will be triggered if the source fails and cannot be recovered. As data is not synchronized to the replica in real-time, there is a small probability of data inconsistency. TencentDB for PostgreSQL provides configurable failover conditions for flexible settings. By default, the system allows switching when both primary-replica sync delay of 1024MB and primary-replica delay of 10 seconds conditions are met. It is recommended to adjust these settings only if you have specific business requirements.
Modifying Data Replication Mode
1. Log in to the TencentDB for PostgreSQL console. In the instance list, click an instance ID or Manage in the Operation column to enter the instance details page.
2. In the Availability Information section of the Instance Details, detailed availability information of the instance is displayed.
2.1 When the data replication mode is set to async, the specific information displayed is as follows:
Info
Note
Data Replication Mode
The data synchronization method between primary and standby instances supports two modes in the current dual-machine high-availability (one-primary-one-replica) architecture: async replication and semi-sync replication.
Instance Availability Status
The current accessibility status of the instance is displayed. When the status is normal, it can accept user requests. If the status is abnormal, it indicates that the instance is currently unable to accept application requests.
Failover Conditions
In case of an unrecoverable failure of the source node, an automatic failover is required, and the replica takes over the service. The system defines failover conditions based on the replication delay size and replication delay time. The default conditions are 1024MB and 10 seconds. Applications can modify the switch conditions based on specific requirements. For detailed switch conditions, please refer to Failover Description.
Primary AZ
Availability zone of the Master node.
Replica AZ
Replica node's availability zone.
2.2 When the data replication mode is set to semi-sync, the specific information is displayed as follows:
Info
Note
Data Replication Mode
The data synchronization method between primary and standby instances supports two modes in the current dual-machine high-availability (one-primary-one-replica) architecture: async replication and semi-sync replication.
Instance Availability Status
The current accessibility status of the instance is displayed. When the status is normal, it can accept user requests. If the status is abnormal, it indicates that the instance is currently unable to accept application requests.
Degradation Conditions
When the instance data replication mode is set to semi-sync replication, the system will automatically degrade the primary-standby replication mode to async replication outside the user-defined conditions to ensure system availability. The degradation conditions are based on primary-standby delay size or delay time. For PostgreSQL instances with major version 9, only the primary-standby delay size condition is supported. For more details, please refer to Degradation Description.
Failover Conditions
When the source node fails and cannot be recovered, an automatic failover is required, and the replica takes over the service. The system defines failover conditions based on the primary-replica delay size or time. Applications can modify the switch conditions based on specific requirements. For more information, please refer to Failover Description.
Primary AZ
Availability zone of the Master node.
Replica AZ
Replica node's availability zone.
3. Click Modify to change the data replication mode of the current instance.
Note:
The change in data replication mode takes effect immediately. Modifying the replication mode may cause a primary-replica switch, which can result in a momentary disconnection. Please ensure that your application has a reconnection mechanism.
