Primary Server
synchronous_standby_names
Parameter description: Specifies a comma-separated list of names of potential standby servers that support synchronous replication.
This parameter is a SIGHUP parameter. Set it based on instructions provided in Table 1.
- The current synchronous standby server is on the top of the list. If the current synchronous standby server is disconnected, it will be replaced immediately with the next-highest-priority standby server. Name of the next-highest-priority standby server is added to the list.
- The standby server name can be specified by setting the environment variable PGAPPNAME.
- ANY num_sync (standby_name [, ...])
- [FIRST] num_sync (standby_name [, ...])
- standby_name [, ...]
- In the preceding command, num_sync indicates the number of standby nodes that need to wait for responses from the transaction, standby_name indicates the name of the standby node, and FIRST and ANY specify the policies for selecting standby nodes for synchronous replication from the listed servers.
- ANY N (dn_instanceId1, dn_instanceId2,...) indicates that any N host names in the brackets are selected as the name list of standby nodes for synchronous replication. For example, ANY 1(dn_instanceId1, dn_instanceId2) indicates that any one of dn_instanceId1 and dn_instanceId2 is used as the standby node for synchronous replication.
- FIRST N (dn_instanceId1, dn_instanceId2, ...) indicates that the first N primary node names in the brackets are selected as the standby node name list for synchronous replication based on the priority. For example, FIRST 1 (dn_instanceId1, dn_instanceId2) indicates that dn_instanceId1 is selected as the standby node for synchronous replication.
- The meanings of dn_instanceId1, dn_instanceId2, ... are the same as those of FIRST 1 (dn_instanceId1, dn_instanceId2, ...).
If you use the gs_guc tool to set this parameter, perform the following operations:
gs_guc reload -Z datanode -N @NODE_NAME@ -D @DN_PATH@ -c "synchronous_standby_names='ANY NODE 1(dn_instanceId1, dn_instanceId2)'";
or
gs_guc reload -Z datanode -N @NODE_NAME@ -D @DN_PATH@ -c "synchronous_standby_names='ANY 1(AZ1, AZ2)'";
Default value: *
most_available_sync
Parameter description: Specifies whether to block the primary server when the primary-standby synchronization fails.
This parameter is a SIGHUP parameter. Set it based on instructions provided in Table 1.
Value range: Boolean
- on indicates that the primary server is not blocked when the synchronization fails.
- off indicates that the primary server is blocked when the synchronization fails.
Default value: off
enable_stream_replication
Parameter description: Specifies whether data and logs are synchronized between primary and standby servers, and between primary and secondary servers.
This parameter is a SIGHUP parameter. Set it based on instructions provided in Table 1.
- This parameter is used for testing performance with standby DNs and without standby DNs. If this parameter is set to off, tests on abnormal scenarios, such as switchover and faults, cannot be performed to prevent inconsistency between the primary, standby, and secondary servers.
- This parameter is a controlled parameter, and you are advised not to set it to off in normal service scenarios.
Value range: Boolean
- on indicates that data and log synchronization is enabled.
- off indicates that data and log synchronization is disabled.
Default value: on
enable_mix_replication
Parameter description: Specifies how WAL files and data are replicated between primary and standby servers, and between primary and secondary servers.
This parameter is an INTERNAL parameter. Its default value is off and cannot be modified.
This parameter cannot be modified in normal service scenarios. That is, the WAL file and data page mixed replication mode is disabled by default.
Value range: Boolean
- on indicates that the WAL file and data page mixed replication mode is enabled.
- off indicates that the WAL file and data page mixed replication mode is disabled.
Default value: off
vacuum_defer_cleanup_age
Parameter description: Specifies the number of transactions by which VACUUM will defer the cleanup of invalid row-store table records. That is, VACUUM and VACUUM FULL do not clean up deleted tuples immediately.
This parameter is a SIGHUP parameter. Set it based on instructions provided in Table 1.
Value range: an integer ranging from 0 to 1000000. 0 means no delay.
Default value: 0
data_replicate_buffer_size
Parameter description: Specifies the amount of memory used by queues when the sender sends data pages to the receiver. The value of this parameter affects the buffer size used during the replication from the primary server to the standby server.
This parameter is a POSTMASTER parameter. Set it based on instructions provided in Table 1.
Value range: an integer ranging from 4096 to 1072693248. The unit is KB.
Default value: 128 MB (131072 KB)
walsender_max_send_size
Parameter description: Specifies the size of the WAL or Sender buffers on the primary server.
This parameter is a POSTMASTER parameter. Set it based on instructions provided in Table 1.
Value range: an integer ranging from 8 to 1048575. The unit is KB.
Default value: 8 MB (8192 KB)
enable_data_replicate
Parameter description: Specifies how data is synchronized between primary and standby servers when the data is imported to a row-store table.
This parameter is a USERSET parameter. Set it based on instructions provided in Table 1.
Value range: Boolean
- on indicates that the primary and standby servers synchronize data using data pages when the data is imported to a row-store table. When replication_type is set to 1, this parameter cannot be set to on. If this parameter is set to on using the GUC tool, its value will be forcibly changed to off.
- off indicates that the primary and standby servers synchronize data using Xlogs when the data is imported to a row-store table.
Default value: off
ha_module_debug
Parameter description: Specifies the replication status log of a specific data block during data replication.
This parameter is a USERSET parameter. Set it based on instructions provided in Table 1.
Value range: Boolean
- on indicates that the status of each data block is recorded in logs during data replication.
- off indicates that the status of each data block is not recorded in logs during data replication.
Default value: off
enable_incremental_catchup
Parameter description: Specifies the data catchup mode between the primary and standby servers.
This parameter is a SIGHUP parameter. Set it based on instructions provided in Table 1.
Value range: Boolean
- on indicates that the standby server uses the incremental catchup mode. That is, the standby server scans local data files on the standby server to obtain the list of differential data files between the primary and standby servers and then performs catchup between the primary and standby servers.
- off indicates that the standby server uses the full catchup mode. That is, the standby server scans all local data files on the primary server to obtain the list of differential data files between the primary and standby servers and then performs catchup between the primary and standby servers.
Default value: on
wait_dummy_time
Parameter description: Specifies the maximum duration for the primary server to wait for the standby servers to start and send the scanning lists when incremental data catchup is enabled in cluster.
This parameter is a SIGHUP parameter. Set it based on instructions provided in Table 1.
Value range: an integer ranging from 1 to 2147483647. The unit is second.
Default value: 300
The unit can only be second.
catchup2normal_wait_time
Parameter description: Specifies the maximum duration that the primary server is blocked during the data catchup on the standby server in the case of a single synchronous standby server.
This parameter is a POSTMASTER parameter. Set it based on instructions provided in Table 1.
Value range: an integer ranging from –1 to 10000. The unit is ms.
- The value –1 indicates that the primary server is blocked until the data catchup on the standby server is complete.
- The value 0 indicates that the primary server is not blocked during the data catchup on the standby server.
- Other values indicate the maximum duration that the primary server is blocked during the data catchup on the standby server. For example, if this parameter is set to 5000, the primary server is blocked until the data catchup on the standby server is complete in 5s.
Default value: –1
sync_config_strategy
Parameter description: Specifies the policy for synchronizing configuration files between the primary node and standby node, and between the standby node and cascaded standby node.
This parameter is a USERSET parameter. Set it based on instructions provided in Table 1.
Value range: enumerated values
- all_node: If this parameter is set to all_node for the primary node, the primary node is allowed to proactively synchronize configuration files to all standby nodes. If this parameter is set to all_node for a standby node, the standby node is allowed to send synchronization requests to its primary node, and the standby node is allowed to proactively synchronize configuration files to all cascaded standby nodes. If this parameter is set to all_node for a cascaded standby node, the current cascaded standby node is allowed to send synchronization requests to its standby node.
- only_sync_node: If this parameter is set to only_sync_node for the primary node, the primary node is only allowed to proactively synchronize configuration files to all standby nodes. If this parameter is set to only_sync_node for a standby node, the standby node is allowed to send synchronization requests to its primary node, and the standby node is not allowed to proactively synchronize configuration files to all cascaded standby nodes. If this parameter is set to only_sync_node for a cascaded standby node, the current cascaded standby node is allowed to send synchronization requests to its standby node.
- none_node: If this parameter is set to none_node for the primary node, the primary node is not allowed to proactively synchronize configuration files to all standby nodes. If this parameter is set to none_node for a standby node, the standby node is not allowed to send synchronization requests to its primary node, and the standby node is not allowed to proactively synchronize configuration files to all cascaded standby nodes. If this parameter is set to none_node for a cascaded standby node, the current cascaded standby node is not allowed to send synchronization requests to its standby node.
Default value: all_node
Note: If this parameter is configured after an upgrade from a version earlier than 503.0.0 to 503.0.0, this parameter cannot be identified after a rollback. Do not set this parameter during the upgrade to 503.0.0.
hadr_recovery_time_target
Parameter description: Specifies whether the standby database instance completes log writing and replay in streaming DR mode.
This parameter is a SIGHUP parameter. Set it based on instructions provided in Table 1.
Value range: an integer ranging from 0 to 3600. The unit is second.
0 indicates that log flow control is disabled. A value from 1 to 3600 indicates that a standby node can write and replay logs within the period specified by hadr_recovery_time_target. This ensures that the logs can be written and replayed within the period specified by hadr_recovery_time_target and the standby database instance can be promoted to primary quickly. If this parameter is set to a small value, the performance of the primary node is affected. If it is set to a large value, the log flow is not effectively controlled.
Default value: 60 (financial edition (data computing))
hadr_recovery_point_target
Parameter description: Specifies the RPO time allowed for the standby database instance to flush logs to disks in streaming DR mode.
This parameter is a SIGHUP parameter. Set it based on instructions provided in Table 1.
Value range: an integer ranging from 0 to 3600. The unit is second.
0 indicates that log flow control is disabled. A value from 1 to 3600 indicates that the standby node can flush logs to disks within the period specified by hadr_recovery_point_target. This ensures that the log difference between the primary and standby database instances is controlled within the period specified by hadr_recovery_point_target during the switchover and the standby database instance can be promoted to primary. If this parameter is set to a small value, the performance of the primary node is affected. If it is set to a large value, the log flow is not effectively controlled.
Default value: 10 (financial edition (data computing))
hadr_super_user_record_path
Parameter description: Specifies the path for storing encrypted files of the hadr_disaster user in the standby cluster in streaming DR mode. This parameter is a SIGHUP parameter. Set it based on instructions provided in Table 2.
Modification suggestion: The value is automatically set by the streaming DR password transfer tool and does not need to be manually added.
Value range: a string
Default value: NULL
check_sync_standby
Parameter description: Specifies whether to enable the standby node check function. After the synchronous_standby_names parameter is correctly configured in the primary/standby scenario, if the synchronous standby node is faulty, the write service on the primary node reports a write failure. This parameter is a USERSET parameter. Set it based on instructions provided in Table 2.
Value range: on or off
- on indicates that the standby node check is enabled.
- off indicates that the standby node check is disabled.
Default value: off
- This parameter cannot be synchronized in job work and autonomous transactions. Otherwise, the check may not take effect.
- If the standby node check is not configured for a specified user or session and the standby node is faulty when the forcible synchronization commit mode is enabled, the write operation on a table causes the query on the same table by another user or in another session to hang. In this case, you need to recover the standby node or manually terminate the hung client.
- The standby node check function cannot be enabled in scenarios (such as VACUUM ANALYZE and gs_clean) where non-write operations trigger log writing. If the standby node does not meet the requirements for synchronizing configurations to the standby node, services will be hung in this scenario. In this case, you need to manually terminate the services.
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