Dual-Cluster DR Query Functions
- gs_get_global_barrier_status()
Description: If two-city 3DC DR is enabled, the primary cluster and standby cluster for DR synchronize logs through OBS. The barrier log is flushed to disks in the primary cluster, and replayed in the standby cluster for DR to determine the archived log progress of the primary cluster and the log replay progress of the standby cluster for DR. gs_get_global_barrier_status is used to query the latest global barrier archived in OBS by the primary cluster.
Return type: text
global_barrier_id: indicates the globally latest barrier ID.
global_achive_barrier_id: indicates the globally latest archived barrier ID.
- gs_get_local_barrier_status()
Description: If two-city 3DC DR is enabled, the primary cluster and standby cluster for DR synchronize logs through OBS. The barrier log is flushed to disks in the primary cluster, and replayed in the standby cluster for DR to determine the archived log progress of the primary cluster and the log replay progress of the standby cluster for DR. gs_get_local_barrier_status is used to query the current log replay status of each node in the standby cluster for DR.
Return type: text
barrier_id: latest barrier ID of a node in the standby cluster for DR.
barrier_lsn: LSN of the latest barrier ID returned by a node in the standby cluster for DR.
archive_lsn: location of archived logs obtained by a node in the standby cluster for DR. This parameter does not take effect currently.
flush_lsn: location of logs that have been flushed to disks on a node in the standby cluster for DR.
- gs_get_global_barriers_status()
Description: If two-city 3DC DR solutions based on OBS are enabled, logs of the primary database instance and multiple standby database instances for DR are synchronized through OBS. The barrier log is flushed to the disk of the primary database instance. The progress of archiving logs of the primary database instance and the progress of replaying logs of the standby database instances for DR are determined by replaying the standby database instances for DR. gs_get_global_barriers_status is used to query the latest global barrier that has been archived in OBS for the primary database instance.
Return type: text
slot_name: name of the slot used for DR.
global_barrier_id: globally latest barrier ID.
global_achive_barrier_id: globally latest archived barrier ID.
- gs_upload_obs_file('slot_name', 'src_file', 'dest_file')
Description: Function used by the primary cluster to upload data to OBS if two-city 3DC DR is enabled.
Return type: void
slot_name: name of the replication slot created by the CN in the primary cluster.
src_file: location of files to be uploaded in the CN data directory of the primary cluster.
dest_file: location of files uploaded to OBS.
- gs_download_obs_file('slot_name', 'src_file', 'dest_file')
Description: Function used by the standby cluster for DR to download data from OBS to the localhost if two-city 3DC DR is enabled.
Return type: void
slot_name: name of the replication slot created by the CN in the standby cluster for DR.
src_file: location of files to be downloaded from OBS.
dest_file: location of downloaded files in the CN data directory of the standby cluster for DR.
- gs_get_obs_file_context('file_name', 'slot_name')
Description: Queries file content on OBS if two-city 3DC DR is enabled.
Return type: text
file_name: name of the file on OBS.
slot_name: name of the replication slot created by the CN in the primary or standby cluster for DR.
- gs_set_obs_file_context('file_name', 'file_context','slot_name')
Description: Creates a file on OBS and writes content into the file if two-city 3DC DR is enabled.
Return type: text
file_name: name of the file on OBS.
file_context: content to be written into the file.
slot_name: name of the replication slot created by the CN in the primary cluster or standby cluster for DR.
- gs_get_hadr_key_cn()
Description: Creates a file on OBS and writes content into the file if two-city 3DC DR is enabled.
Return type: text
file_name: name of the file on OBS.
file_context: content to be written into the file.
slot_name: name of the replication slot created by the CN in the primary cluster or standby cluster for DR.
- gs_hadr_has_barrier_creator()
Description: Checks whether the barrier_creator thread exists on the current CN if two-city 3DC DR is enabled. If the thread exists, true is returned (the SYSADMIN permission is required).
Return type: Boolean
Note: This function is used only when a planned switchover is performed in the standby cluster for DR.
- gs_hadr_in_recovery()
Description: Checks whether the current node is in barrier-based log restoration if two-city 3DC DR is enabled. If the current node is in barrier-based log restoration, true is returned. Only after the log restoration is complete, can the standby cluster for DR be promoted to the production cluster during the switchover process. This operation must be performed by system administrators.
Return type: Boolean
This function is used only when a planned switchover is performed in the standby cluster for DR.
- gs_streaming_dr_get_switchover_barrier()
Description: Checks whether the CN and main standby DN in the standby cluster for DR have received the switchover barrier logs and replayed the logs in the streaming replication-based two-city 3DC DR solution. If it has, true is returned. In the standby cluster for DR, the procedure for promoting the DR database instance to the production database instance in the switchover process can be started only after the switchover barrier logs of all DNs are replayed (the SYSADMIN permission is required).
Return type: Boolean
Note: This function is used only when a planned switchover is performed on the standby database instance for DR in streaming DR solutions.
- gs_streaming_dr_service_truncation_check()
Description: Checks whether the CN and primary DN in the primary cluster has sent the switchover barrier logs in the streaming replication-based two-city 3DC DR solution. If it has, true is returned. The procedure for demoting the production database instance to the standby database instance for DR in the switchover process can be started only after the logs are sent (the SYSADMIN permission is required).
Return type: Boolean
Note: This function is used only when a planned switchover is performed on the standby database instance for DR.
- gs_hadr_local_rto_and_rpo_stat()
Description: Displays the log flow control information of the local database instance and DR database instance for streaming DR. (If this command is executed on a node that does not participate in streaming DR, for example, a standby DN or a CN, no information may be returned.)
Return type: record. The types and meanings of the fields are as follows:
Parameter
Type
Description
hadr_sender_node_name
text
Node name, including the primary database instance and the main standby node of the standby database instance.
hadr_receiver_node_name
text
Name of the main standby node of the standby database instance.
source_ip
text
IP address of the primary DN of the primary database instance.
source_port
int
Communication port of the primary DN of the primary database instance.
dest_ip
text
IP address of the main standby DN of the standby database instance.
dest_port
int
Communication port of the main standby DN of the standby database instance.
current_rto
int
Flow control information, that is, log RTO time of the current primary and standby database instances (unit: second).
target_rto
int
Flow control information, that is, the RTO time between the target primary and standby database instances (unit: second).
current_rpo
int
Flow control information, that is, log RPO time of the current primary and standby database instances (unit: second).
target_rpo
int
Flow control information, that is, the RPO time between the target primary and standby database instances (unit: second).
rto_sleep_time
int
RTO flow control information, that is, the expected sleep time (unit: μs) required by walsender on the host to reach the specified RTO.
rpo_sleep_time
int
RPO flow control information, that is, the expected sleep time (unit: μs) required for inserting Xlogs on the host to reach the specified RPO.
- gs_hadr_remote_rto_and_rpo_stat()
Description: Displays the log flow control information of all other shards or CN database instances and DR database instances for streaming DR. (Generally, this command is executed on CNs. If this command is executed on DNs, no information may be returned.)
Return type: record. The types and meanings of the fields are as follows:
Parameter
Type
Description
hadr_sender_node_name
text
Node name, including the primary database instance and the main standby node of the standby database instance.
hadr_receiver_node_name
text
Name of the main standby node of the standby database instance.
source_ip
text
IP address of the primary DN of the primary database instance.
source_port
int
Communication port of the primary DN of the primary database instance.
dest_ip
text
IP address of the main standby DN of the standby database instance.
dest_port
int
Communication port of the main standby DN of the standby database instance.
current_rto
int
Flow control information, that is, log RTO time of the current primary and standby database instances (unit: second).
target_rto
int
Flow control information, that is, the RTO time between the target primary and standby database instances (unit: second).
current_rpo
int
Flow control information, that is, log RPO time of the current primary and standby database instances (unit: second).
target_rpo
int
Flow control information, that is, the RPO time between the target primary and standby database instances (unit: second).
rto_sleep_time
int
RTO flow control information, that is, the expected sleep time (unit: μs) required by walsender on the host to reach the specified RTO.
rpo_sleep_time
int
RPO flow control information, that is, the expected sleep time (unit: μs) required by xlogInsert on the host to reach the specified RPO.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot