Configuring Crash Safe Master

MyRocks offers different crash safety configuration templates, depending on your crash safety requirements. Here are three common configuration examples.

1. Crash Safe on unplanned host restart

log-bin
sync-binlog=1
binlog-order-commit=1
rocksdb-flush-log-at-trx-commit=1
rocksdb-wal-recovery-mode=1
rocksdb-enable-2pc=1

This is "fully durable" configuration. MyRocks flushes to both binary logs (binlog commit) and WAL (rocksdb prepare) for each commit. In case of master crash once the master has restarted and gone through recovery, slaves will be able to restart replication without changing anything.

2. Crash Safe on unplanned mysqld restart

log-bin
sync-binlog=0
binlog-order-commit=1
rocksdb-flush-log-at-trx-commit=2
rocksdb-wal-recovery-mode=1
rocksdb-enable-2pc=1

This is "durable" on mysqld restart (i.e. hitting a Segmentaion Fault and restarting), but not durable on unplanned host reboot. This configuration is useful if you have a solid auto-failover environment that works on master host failure.

3. Crash Safe if you always discard binary logs before restart

log-bin
sync-binlog=0
binlog-order-commit=1
rocksdb-flush-log-at-trx-commit=2
rocksdb-wal-recovery-mode=0
rocksdb-enable-2pc=0

This configuration is useful if you have a solid auto-failover environment that works on any master failure. If the master restarts and continues to serve write requests, it may result in data inconsistency between master and slaves.