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

[mysqld]
log-bin
sync-binlog=1
binlog-order-commit=1
rocksdb-flush-log-at-trx-commit=1
rocksdb-wal-recovery-mode=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

[mysqld]
log-bin
sync-binlog=0
binlog-order-commit=1
rocksdb-flush-log-at-trx-commit=2
rocksdb-wal-recovery-mode=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

[mysqld]
log-bin
sync-binlog=0
binlog-order-commit=1
rocksdb-flush-log-at-trx-commit=2
rocksdb-wal-recovery-mode=0

This is not "durable" but 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 (i.e. continues its role as master), it may result in data inconsistency between master and slaves.