Stable devices: considerations

Like any application, Replication Server is subject to standard I/O and I/O device best practices. You should consider the impact of contention for disk Read/Write heads and I/O channels when planning how your stable devices will be used to support your stable queues. To the extent that you can dedicate one or more devices to each queue, I/O will be less of a performance issue. This includes guarding the devices from use by other processes such as primary or replicate databases or RSSDs. You can use the database connection parameter disk_affinity to establish affinities between queues and specific partitions that are supported by dedicated devices.

For stable queues initialized on UNIX operating system files, the sqm_write_flush configuration parameter controls whether or not writes to memory buffers are flushed to the disk before the write operation completes.

When sqm_write_flush is on, Replication Server opens stable queues using the O_DSYNC flag. This flag ensures that writes are flushed from memory buffers to the disk before write operations complete. Because the data is stored on physical media, Replication Server can always recover the data in the event of a system failure. This is the default setting.

When sqm_write_flush is off, writes may be buffered in the UNIX file system. If subsequent writes fail, automatic recovery is not guaranteed. Testing has shown that when comparing the write rates of the various options for partition types and I/O flushing that writing to a buffered file system with sqm_write_flush on is up to five times slower than writes to raw partitions.

Further, testing has shown that writes to raw partitions are up to seven times slower than writes to buffered file systems with sqm_write_flush off. Turning sqm_write_flush off when using UNIX Buffered file systems for stable devices provides peak I/O performance but with an increased risk of data loss. Provided you keep primary database transaction log backups, that risk can be reduced or eliminated.

For file system partitions, direct I/O reduces the I/O latency as compared to the synchronous I/O, DSYNC. Configure direct I/O using:

configure replication server set sqm_write_flush to
"dio"

This command enables direct I/O and is effective only when the stable queue is on the file system. The direct I/O method allows the Replication Server to read or write directly to the disk without the buffering of the file system. Adjust the stable queue cache properly. A proper cache size ensures that most read transactions are completed within the cache.

This command is static, which means you must restart the server for it to take effect.