Settings
wal_level
Parameter description: Specifies the level of information to be written to the WAL. The value cannot be empty or commented out.
This parameter is a POSTMASTER parameter. Set it based on instructions provided in Table 1.
- To enable WAL archiving and data streaming replication between primary and standby servers, set this parameter to archive, hot_standby, or logical.
- This parameter can be set to minimal only in a single-server system. When the parameter value is minimal, archive_mode must be set to off, hot_standby must be set to off, and max_wal_senders must be set to 0. Otherwise, the database startup fails.
- If this parameter is set to archive, hot_standby must be set to off. Otherwise, the database startup fails. However, hot_standby cannot be set to off in a primary-standby deployment. For details, see the description of the hot_standby parameter.
Value range: enumerated values
- minimal
Advantages: Certain bulk operations (including creating tables and indexes, executing cluster operations, and copying tables) are safely skipped in logging, which can make those operations much faster.
Disadvantages: WALs contain only basic information required for recovery from a database server crash or an emergency shutdown. Data cannot be restored from archived WALs.
- archive
Adds logging required for WAL archiving, supporting the database restoration from archives.
- hot_standby
- Further adds information required to run SQL queries on a standby server and takes effect after a server restart.
- To enable read-only queries on a standby server, the wal_level parameter must be set to hot_standby on the primary server and the same value must be set on the standby server. There are few measurable differences in performance between using hot_standby and archive levels. However, feedback is welcome if any differences in their impacts on product performance are noticeable.
- logical
This parameter indicates that WALs support logical replication.
Default value: hot_standby
fsync
Parameter description: Specifies whether the GaussDB server uses the fsync() function (see wal_sync_method) to ensure that updates can be written to disks in a timely manner.
This parameter is a SIGHUP parameter. Set it based on instructions provided in Table 1.
- Using the fsync() function ensures that the data can be recovered to a known state when an OS or a hardware crashes.
- Setting this parameter to off may result in unrecoverable data corruption in a system crash.
Value range: Boolean
- on indicates that the fsync() function is used.
- off indicates that the fsync() function is not used.
Default value: on
synchronous_commit
Parameter description: Specifies the synchronization mode of the current transaction.
This parameter is a USERSET parameter. Set it based on instructions provided in Table 1.
- The primary node writes the log content to the local memory.
- The primary node writes the logs in the local memory to the local file system.
- The primary node flushes logs in the local file system to disks.
- The primary node sends the log content to the standby node.
- The standby node receives the log content and saves it to the local memory.
- The standby node writes logs in the local memory to the local file system.
- The standby node flushes logs in the local file system to disks.
- The standby node replays logs to complete the incremental update of data files.
Value range: enumerated values
- on: The primary node waits for the standby node to flush logs to disks before committing a transaction.
- off: The primary node commits transactions without waiting for the primary node to flush logs to disks. This mode is also called asynchronous commit.
- local: The primary node waits for the primary node to flush logs to disks before committing a transaction. This mode is also called local commit.
- remote_write: The primary node waits for the standby node to write logs to the file system before committing a transaction. (The logs do not need to be flushed to disks.)
- remote_receive: The primary node waits for the standby node to receive logs before committing a transaction. (The logs do not need to be written to the file system.)
- remote_apply: The primary node waits for the standby node to complete log replay before committing a transaction.
- true: same as on.
- false: same as off.
- yes: same as on.
- no: same as off.
- 1: same as on.
- 0: same as off.
- 2: same as remote_apply.
Default value: on
wal_sync_method
Parameter description: Specifies the method used for forcing WAL updates out to disk.
This parameter is a SIGHUP parameter. Set it based on instructions provided in Table 1.
If fsync is set to off, the setting of this parameter does not take effect because WAL file updates will not be forced out to disk.
Value range: enumerated values
- open_datasync indicates that WAL files are opened with the O_DSYNC option.
- fdatasync indicates that fdatasync() is called at each commit. (SUSE 10 and SUSE 11 are supported.)
- fsync_writethrough indicates that fsync() is called at each commit to force data in the buffer to be written to the disk.
wal_sync_method can be set to fsync_writethrough on a Windows platform, but this setting has the same effect as setting the parameter to fsync.
- fsync indicates that fsync() is invoked at each commit (SUSE 10 and SUSE 11 are supported).
- open_sync indicates that the open() with the O_SYNC option is used to write WAL files (SUSE 10 and SUSE 11 are supported).
Not all platforms support the preceding parameters.
Default value: fdatasync
full_page_writes
Parameter description: Specifies whether the GaussDB server writes the entire content of each disk page to WALs during the first modification of that page after a checkpoint. When the incremental checkpoint function and enable_double_write are enabled at the same time, full_page_writes is not used.
This parameter is a SIGHUP parameter. Set it based on instructions provided in Table 1.
- This parameter is needed because a page write that is in process during an OS crash might be only partially completed, leading to an on-disk page that contains a mix of old and new data. The row-level change data normally stored in WALs will not be enough to completely restore such a page during post-crash recovery. Storing the full page image guarantees that the page can be correctly restored, but at the price of increasing the amount of data that must be written to WALs.
- Setting this parameter to off might lead to unrecoverable data corruption after a system failure. It might be safe to set this parameter to off if you have hardware (such as a battery-backed disk controller) or file-system software (such as ReiserFS 4) that reduces the risk of partial page writes to an acceptably low level.
Value range: Boolean
- on indicates that this feature is enabled.
- off indicates that this feature is disabled.
Default value: on
wal_log_hints
Parameter description: Specifies whether to write an entire page to WALs during the first modification of that page after a checkpoint, even for non-critical modifications of so-called hint bits. You are advised not to modify the setting.
This parameter is a POSTMASTER parameter. Set it based on instructions provided in Table 1.
Value range: Boolean
- on indicates that the entire page is written to WALs.
- off indicates that the entire page is not written to WALs.
Default value: on
wal_buffers
Parameter description: Specifies the number of XLOG_BLCKSZ used for storing WAL data. The size of each XLOG_BLCKSZ is 8 KB.
This parameter is a POSTMASTER parameter. Set it based on instructions provided in Table 1.
Value range: –1 to 218. The minimum value is –1 and the maximum value is 262144. The unit is 8 KB.
- If this parameter is set to –1, the value of wal_buffers is automatically adjusted to 1/64 of shared_buffers. The minimum value is 8 XLOG_BLCKSZ and the maximum value is 2048 XLOG_BLCKSZ, if the automatically adjusted value is less than the minimum value, the value is adjusted to the minimum value. If the automatically adjusted value is greater than the maximum value, the value is adjusted to the maximum value.
- If this parameter is set to a value other than –1 and smaller than 4, the value 4 is used.
Default value:
1 GB (128-core CPU/1024-GB memory, 104-core CPU/1024-GB memory, 96-core CPU/1024-GB memory, 96-core CPU/768-GB memory, 64-core CPU/512-GB memory, 60-core CPU/480-GB memory, and 32-core CPU/256-GB memory); 512 MB (16-core CPU/128-GB memory); 256 MB (8-core CPU/64-GB memory); 128 MB (4-core CPU/32-GB memory); 64 MB (4-core CPU/16-GB memory)
Setting suggestions: The content of the WAL buffers is written to disks at every transaction commit, so extremely large values are unlikely to provide a significant increase in system performance. However, setting this parameter to hundreds of megabytes can improve the disk write performance on a server to which a large number of transactions are committed at the same time. The default value meets user requirements in most cases.
wal_writer_delay
Parameter description: Specifies the delay between activity rounds for the WAL writer.
This parameter is a SIGHUP parameter. Set it based on instructions provided in Table 1.
A longer delay might lead to insufficient WAL buffer and a shorter delay leads to continuously writing of the WALs, thereby increasing the load of disk I/O.
Value range: an integer ranging from 1 to 10000. The unit is millisecond.
Default value: 200 ms
commit_delay
Parameter description: Specifies the duration for committed data to be stored in the WAL buffer.
This parameter is a USERSET parameter. Set it based on instructions provided in Table 1.
- When this parameter is set to a non-zero value, the committed transaction is stored in the WAL buffer instead of being written to the WAL immediately. Then the WAL writer process flushes the buffer out to disks periodically.
- If system load is high, other transactions are probably ready to be committed within the delay. If no other transactions are ready to be committed, the delay is a waste of time.
Value range: an integer ranging from 0 to 100000. The unit is μs. 0 indicates no delay.
Default value: 0
commit_siblings
Parameter description: Specifies a threshold on the number of concurrent open transactions. If the number of concurrent open transactions is greater than the value of this parameter, a transaction that initiates a commit request will wait for a period of time specified by commit_delay. Otherwise, this transaction is written into WALs immediately.
This parameter is a USERSET parameter. Set it based on instructions provided in Table 1.
Value range: an integer ranging from 0 to 1000
Default value: 5
wal_block_size
Parameter description: Specifies the size of a WAL disk block.
This parameter is a fixed INTERNAL parameter and cannot be modified.
Value range: an integer. The unit is byte.
Default value: 8192
wal_segment_size
Parameter description: Specifies the size of a WAL segment file.
This parameter is a fixed INTERNAL parameter and cannot be modified.
Value range: an integer. The unit is 8 KB.
Default value: 16 MB (2048 x 8 KB)
walwriter_cpu_bind
Parameter description: Specifies the CPU core bound to the WAL write thread. This parameter is used together with the thread pool parameter.
This parameter is a POSTMASTER parameter. Set it based on instructions provided in Table 1.
Value range: an integer ranging from –1 to the number of cores minus 1
Default value: –1
walwriter_sleep_threshold
Parameter description: Specifies the number of times that idle Xlogs are refreshed before the xlogflusher enters the sleep state. If the number of times reaches the threshold, the xlogflusher enters the sleep state.
This parameter is a SIGHUP parameter. Set it based on instructions provided in Table 1.
Value range: an integer ranging from 1 to 50000
Default value: 500 (128-core CPU/1024-GB memory, 104-core CPU/1024-GB memory, 96-core CPU/1024-GB memory, 96-core CPU/768-GB memory, 64-core CPU/512-GB memory, and 60-core CPU/480-GB memory); 50 (32-core CPU/256-GB memory, 16-core CPU/128-GB memory, 8-core CPU/64-GB memory, 4-core CPU/32-GB memory, and 4-core CPU/16-GB memory)
wal_file_init_num
Parameter description: Specifies the number of Xlog segment files to be created by the WAL writer.
This parameter is a POSTMASTER parameter. Set it based on instructions provided in Table 1.
Value range: an integer ranging from 0 to 1000000
Default value: 10 (128-core CPU/1024-GB memory, 104-core CPU/1024-GB memory, 96-core CPU/1024-GB memory, 96-core CPU/768-GB memory, 64-core CPU/512-GB memory, and 60-core CPU/480-GB memory); 0 (32-core CPU/256-GB memory, 16-core CPU/128-GB memory, 8-core CPU/64-GB memory, 4-core CPU/32-GB memory, and 4-core CPU/16-GB memory)
xlog_file_path
Parameter description: Specifies the path of the Xlog shared disk in dual-database instance shared storage scenarios. This parameter is configured by the OM during database system initialization. You are not advised to modify the configuration.
This parameter is a POSTMASTER parameter. Set it based on instructions provided in Table 1.
Value range: a string
Default value: NULL
xlog_file_size
Parameter description: Specifies the size of the Xlog shared disk in dual-database instance shared storage scenarios. This parameter is configured by the OM during database system initialization. You are not advised to modify the configuration.
This parameter is a POSTMASTER parameter. Set it based on instructions provided in Table 1.
Value range: a long integer ranging from 5053733504 to 576460752303423487. The unit is byte.
Default value: 549755813888
xlog_lock_file_path
Parameter description: Specifies the path of the lock file preempted by the Xlog shared disk in dual-database instance shared storage scenarios. This parameter is configured by the OM during database system initialization. You are not advised to modify the configuration.
This parameter is a POSTMASTER parameter. Set it based on instructions provided in Table 1.
Value range: a string
Default value: NULL
force_promote
Parameter description: Specifies whether to enable the forcible switchover function on the standby node.
When a database instance is faulty, the forcible switchover enables the database instance to recover services as soon as possible at the cost of losing some data. This is an escape method used when the database instance is unavailable. You are not advised to trigger this method frequently. You are not advised not to use this function if you are not clear about the impact of data loss on services.
To use this function, you need to enable it on the DN and CM Server and restart the database instance for the setting to take effect. For details about how to enable the forcible switchover function on the standby node, see "Emergency Handling > Performing a Forcible Primary/Standby Switchover" in Troubleshooting.
Value range: 0 or 1
The value 0 indicates that the function is disabled, and the value 1 indicates that the function is enabled.
Default value: 0
wal_debug
Parameter description: Specifies whether to output WAL-related debugging information. This parameter is available only when WAL_DEBUG is enabled during compilation.
This parameter is a SUSET parameter. Set it based on instructions provided in Table 1.
Value range: Boolean
Default value: false
wal_flush_timeout
Parameter description: Specifies the timeout interval for traversing WalInsertStatusEntryTbl. It is the maximum wait time for the adaptive Xlog disk flushing I/O to traverse WalInsertStatusEntryTbl.
This parameter is a SIGHUP parameter. Set it based on instructions provided in Table 1.
If the timeout interval is too long, the Xlog flushing frequency may decrease, reducing the Xlog processing performance.
Value range: an integer ranging from 0 to 90000000 (μs)
Default value:2
wal_flush_delay
Parameter description: Specifies the wait interval when an entry in the WAL_NOT_COPIED state is encountered during WalInsertStatusEntryTbl traversal.
This parameter is a SIGHUP parameter. Set it based on instructions provided in Table 1.
Value range: an integer ranging from 0 to 90000000 (μs)
Default value:1
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