- Release Notes and Announcements
- Release Notes
- Open-Source Plugin Privilege Escalation Has Vulnerability Risk for PostgreSQL
- Announcements
- Security Risk Statement for Creating Partial Plugins in PostgreSQL Cloud Database
- TencentDB for PostgreSQL Will Start Billing for Backup Space
- Some Extensions on Lower Kernel Version Can't Be Created and Upgraded in TencentDB for PostgreSQL
- Announcement on the Risk of Privilege Escalation Vulnerability in Cloud Database PostgreSQL Open Source Plugin
- Product Introduction
- Purchase Guide
- Getting Started
- Kernel Version Introduction
- Operation Guide
- Instance Management
- Upgrading Instance
- Read-Only Instance
- Account Management
- Database Optimization
- Parameter Management
- Log management
- Backup and Restoration
- Extension Management
- Network Management
- Access Management
- Data Encryption
- Security Groups
- Monitoring and Alarms
- Tag
- PostgreSQL for Serverless
- Best Practice
- postgres_fdw Extension for Cross-database Access
- Automatically Creating Partition in PostgreSQL
- Searching in High Numbers of Tags Based on pg_roaringbitmap
- Querying People Nearby with One SQL Statement
- Configuring TencentDB for PostgreSQL as GitLab's External Data Source
- Supporting Tiered Storage Based on cos_fdw Extension
- Implement Read/Write Separation via pgpool
- API Documentation
- History
- Introduction
- API Category
- Making API Requests
- Instance APIs
- DescribeDBInstanceHAConfig
- SwitchDBInstancePrimary
- ModifyDBInstanceChargeType
- ModifyDBInstanceHAConfig
- UpgradeDBInstanceKernelVersion
- CreateInstances
- DescribeDBInstanceAttribute
- DescribeDBInstances
- InitDBInstances
- UpgradeDBInstance
- SetAutoRenewFlag
- RestartDBInstance
- RenewInstance
- ModifyDBInstancesProject
- ModifyDBInstanceName
- DestroyDBInstance
- IsolateDBInstances
- DisIsolateDBInstances
- ModifySwitchTimePeriod
- ModifyDBInstanceSpec
- ModifyDBInstanceDeployment
- DescribeEncryptionKeys
- CreateDBInstances
- Read-only Replica APIs
- Backup and Restoration APIs
- DescribeBackupDownloadRestriction
- ModifyBackupDownloadRestriction
- DescribeDBXlogs
- DescribeDBBackups
- ModifyBackupPlan
- DescribeCloneDBInstanceSpec
- DescribeBackupPlans
- DescribeAvailableRecoveryTime
- CloneDBInstance
- ModifyBaseBackupExpireTime
- DescribeLogBackups
- DescribeBaseBackups
- DescribeBackupSummaries
- DescribeBackupOverview
- DescribeBackupDownloadURL
- DeleteLogBackup
- DeleteBaseBackup
- CreateBaseBackup
- Parameter Management APIs
- Network APIs
- Security Group APIs
- Performance Optimization APIs
- Account APIs
- Specification APIs
- PostgreSQL for Serverless APIs
- Data Types
- Error Codes
- FAQs
- Service Agreement
- Glossary
- Contact Us
- Release Notes and Announcements
- Release Notes
- Open-Source Plugin Privilege Escalation Has Vulnerability Risk for PostgreSQL
- Announcements
- Security Risk Statement for Creating Partial Plugins in PostgreSQL Cloud Database
- TencentDB for PostgreSQL Will Start Billing for Backup Space
- Some Extensions on Lower Kernel Version Can't Be Created and Upgraded in TencentDB for PostgreSQL
- Announcement on the Risk of Privilege Escalation Vulnerability in Cloud Database PostgreSQL Open Source Plugin
- Product Introduction
- Purchase Guide
- Getting Started
- Kernel Version Introduction
- Operation Guide
- Instance Management
- Upgrading Instance
- Read-Only Instance
- Account Management
- Database Optimization
- Parameter Management
- Log management
- Backup and Restoration
- Extension Management
- Network Management
- Access Management
- Data Encryption
- Security Groups
- Monitoring and Alarms
- Tag
- PostgreSQL for Serverless
- Best Practice
- postgres_fdw Extension for Cross-database Access
- Automatically Creating Partition in PostgreSQL
- Searching in High Numbers of Tags Based on pg_roaringbitmap
- Querying People Nearby with One SQL Statement
- Configuring TencentDB for PostgreSQL as GitLab's External Data Source
- Supporting Tiered Storage Based on cos_fdw Extension
- Implement Read/Write Separation via pgpool
- API Documentation
- History
- Introduction
- API Category
- Making API Requests
- Instance APIs
- DescribeDBInstanceHAConfig
- SwitchDBInstancePrimary
- ModifyDBInstanceChargeType
- ModifyDBInstanceHAConfig
- UpgradeDBInstanceKernelVersion
- CreateInstances
- DescribeDBInstanceAttribute
- DescribeDBInstances
- InitDBInstances
- UpgradeDBInstance
- SetAutoRenewFlag
- RestartDBInstance
- RenewInstance
- ModifyDBInstancesProject
- ModifyDBInstanceName
- DestroyDBInstance
- IsolateDBInstances
- DisIsolateDBInstances
- ModifySwitchTimePeriod
- ModifyDBInstanceSpec
- ModifyDBInstanceDeployment
- DescribeEncryptionKeys
- CreateDBInstances
- Read-only Replica APIs
- Backup and Restoration APIs
- DescribeBackupDownloadRestriction
- ModifyBackupDownloadRestriction
- DescribeDBXlogs
- DescribeDBBackups
- ModifyBackupPlan
- DescribeCloneDBInstanceSpec
- DescribeBackupPlans
- DescribeAvailableRecoveryTime
- CloneDBInstance
- ModifyBaseBackupExpireTime
- DescribeLogBackups
- DescribeBaseBackups
- DescribeBackupSummaries
- DescribeBackupOverview
- DescribeBackupDownloadURL
- DeleteLogBackup
- DeleteBaseBackup
- CreateBaseBackup
- Parameter Management APIs
- Network APIs
- Security Group APIs
- Performance Optimization APIs
- Account APIs
- Specification APIs
- PostgreSQL for Serverless APIs
- Data Types
- Error Codes
- FAQs
- Service Agreement
- Glossary
- Contact Us
Supported Methods to Replicate Data
Database instance replication refers to the synchronization of data by configuring one or more backup databases for the server, distributing PostgreSQL data across multiple systems. TencentDB for PostgreSQL supports the following two data replication modes:
Asynchronous Replication
Asynchronous replication for TencentDB for PostgreSQL adopts the one-master-one-standby architecture.
After receiving a data update (including insert, update and delete operations) request from an application, the master performs the update operation. When the update is completed, the master immediately responds to the application and replicates the data to the slave.
In the process of data update, the master does not need to wait for the response of the slave. Therefore, the database instances of asynchronous replication usually have higher performance (for specific performance, see Test Results), and the unavailability of the slave does not affect the service provided by the master. However, because the data is not synchronized to the slave in real time, if a fault occurs on the master while the slave is delayed and a switch occurs, there is a slight chance of causing data inconsistency.
Note:
By default, TencentDB for PostgreSQL adopts asynchronous replication for data replication.
Semi-synchronous Replication
Semi-synchronous replication of TencentDB for PostgreSQL adopts a one-master-one-standby architecture.
An application initiates a data update request (including insert, update, delete operations). After the master completes the update operation, it immediately replicates the data to the slave. Only after the slave **receives the data and writes it to the WAL (without executing)**, it returns a success message to the master. The master must only return a response to the application program after receiving the success message from the slave.
Only in the case of a data replication exception (the slave node is unavailable or there is a network issue impacting data replication), the master suspends (for approximately 10 seconds by default in PostgreSQL) its response to the application and downgrades the replication method to asynchronous replication. When data replication is restored to normal, semi-synchronous replication will be restored.
Degradation Description
Fault Degradation
If the current data replication mode of PostgreSQL is semi-synchronous, when data replication encounters an exception (either the slave node is unavailable or an exception occurs in the network used for data replication), the master suspends responding to the application (about 10 seconds for TencentDB for PostgreSQL by default), and downgrades the master-slave replication mode to asynchronous to ensure system availability. Once the high-availability system detects that data replication returns to normal, the master-slave replication mode will be restored to semi-synchronous replication.
Note:
Fault degradation in TencentDB for PostgreSQL's high-availability system is the default behavior. To ensure high availability for the system, currently, the setting cannot be changed.
Latency Degradation
If you have specific needs, you can enable latency degradation under semi-synchronous replication. Once delayed degradation is enabled, TencentDB for PostgreSQL's high-availability system will determine the master-slave replication latency based on the conditions you have set. Exceeding the latency will trigger semi-synchronous degradation to asynchronous. It is recommended that only this feature be enabled for highly latency-sensitive businesses.
The conditions for latency degradation are the size or time of master-slave synchronization. You can refer to the metrics of log write delay (bytes) and log write time delay (seconds) on the standby database. For more details, see Master/Slave Latency Monitoring Metrics.
Failover Description
When the instance is in asynchronous replication mode or when semi-synchronous is downgraded to asynchronous replication, a master/slave switch is triggered when the master fails and cannot recover. As the data is not synchronized to the slave in real-time, there is a small probability that it may lead to data inconsistency. In TencentDB for PostgreSQL failover conditions can be flexibly configured. By default, the system allows switching when both conditions of master/slave synchronous delay of 10240 MB and master/slave delay of 10 seconds are met. It is recommended that changes be made only if you have special business requirements.
Modifying Data Replication Mode
1. Log in to the PostgreSQL Console. In the instance list, click the Instance ID or Operation in the Manage column to open 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 asynchronous, the specific display information is as follows:
Information | Description |
Data Replication Mode | For the data synchronization mode between the master and the slave, the current two-machine high availability (one master and one slave) architecture supports asynchronous replication and semi-synchronous replication. |
Instance Availability Status | It displays the current accessibility status of the instance. When the status is normal, user requests are normally received. If the status is abnormal, the instance currently cannot accept application requests. |
| |
Failover Condition | When the master node fails and cannot recover, an automatic failover is required, with the slave providing the service. At this time, the system defines the failover conditions, which are the master-slave latency size and the master-slave latency time. The system's default conditions are 10240 MB and 10 seconds. For specific failover conditions, see Failover Description. |
Master Availability Zone | It refers to the availability zone of the master node. |
Slave Availability Zone | It refers to the availability zone of the slave node. |
2.2 The specific display information is as follows when the data replication mode is semi-synchronous:
Information | Description |
Data Replication Mode | For the data synchronization mode between the master and the slave, the current two-machine high availability (one master and one slave) architecture supports asynchronous replication and semi-synchronous replication. |
Instance Availability Status | It displays the current accessibility status of the instance. When the status is normal, user requests are normally received. If the status is abnormal, the instance currently cannot accept application requests. |
Fault Degradation Conditions | When the data replication mode of the instance is semi-synchronous replication, the system will automatically degrade the master and slave replication method to asynchronous to ensure system availability outside the range of user-set conditions. This degradation condition is the master and standby latency size or latency time. Among them, PostgreSQL instances with a large version number of 9 only support the condition of master and standby latency size. For details, see the regression explanation. |
Failover Condition | When the master node fails and cannot be recovered, an automatic failover is required, to switch to the slave to provide service. At this time, the system has defined the failover conditions, which are the size or time of master-slave latency. Applications can modify the switch conditions based on special needs. For details, see Failover Description. |
Master Availability Zone | It refers to the availability zone of the master node. |
Slave Availability Zone | It refers to the availability zone of the slave node. |
3. Click Modify to change the current instance's data replication mode.
Note:
Changes to the data replication mode are effective immediately, and modifying the data method may cause a master/slave switch. There will be a momentary disconnection during the master/slave switch, please ensure the application is reconnected.
Yes
No
Was this page helpful?