MyRocks Crash Recovery

MyRocks supports crash recovery. Crash recovery is done by replaying transaction logs from WAL (Write Ahead Log) files. MyRocks has a system variable rocksdb_wal_recovery_mode to control how to apply logs, if any of the WAL entries is corrupted. This variable can be any of the following options:

• 0: If a corrupted WAL entry is detected as the last entry in the WAL, truncate the entry and start up normally; otherwise, refuse to start.

• 1 (default): If a corrupted WAL entry is detected, fail to start. This is the most conservative recovery mode.

• 2: If a corrupted WAL entry is detected in the middle of the WAL, truncate all of WAL entries after that (even though there may be uncorrupted entries) and then start up normally. For Replication Slaves, this option is fine, since the slave instance can recover any lost data from the master without breaking consistency. For Replication Masters, this option may end up losing data if you do not run failover. For example, if the master crashed and was restarted (by mysqld_safe, or auto restart after OS reboot) with this mode and it silently truncated several WAL entries, the master would lose some data which may be present on one or more slaves.

• 3: If a corrupted WAL entry is detected in the middle of the WAL, skip the WAL entry and continue to apply as many healthy WAL entries as possible. This is the most dangerous recovery option and it is not generally recommended.