Delayed Replay
Availability
This feature is available since openGauss 2.0.0.
Introduction
The time for a standby node to replay can be delayed.
Benefits
By default, the standby server restores the Xlog records from the primary server as soon as possible. This function allows you to delay the time for a standby node to replay Xlog records. In this case, you can query a copy that records data before a period of time, which helps correct errors such as misoperations.
Description
The GUC parameter recovery_min_apply_delay can be used to set the delay time so that a standby server can replay Xlog records from the primary server after a delay time.
Value range: an integer ranging from 0 to INT_MAX. The unit is ms.
Default value: 0 (no delay)
Enhancements
None.
Constraints
- The recovery_min_apply_delay parameter is invalid on the primary node. It must be set on the standby node to be delayed.
- The delay time is calculated based on the timestamp of transaction commit on the primary server and the current time on the standby server. Therefore, ensure that the clocks of the primary and standby servers are the same.
- Operations without transactions are not delayed.
- After the primary/standby switchover, if the original primary server needs to be delayed, you need to manually set this parameter.
- When synchronous_commit is set to remote_apply, synchronous replication is affected by the delay. Each commit message is returned only after the replay on the standby server is complete.
- Using this feature also delays hot_standby_feedback, which may cause the primary server to bloat, so be careful when using both.
- If a DDL operation (such as DROP or TRUNCATE) that holds an AccessExclusive lock is performed on the primary server, the query operation on the operation object on the standby server will be returned only after the lock is released during the delayed replay of the record on the standby server.
Dependencies
None.
Feedback