MyRocks and Replication
There are certain details about how MyRocks works with Replication.
MyRocks and statement-based replication
Statement-based replication works as follows: SQL statements are executed on the master (possibly concurrently). They are written into the binlog (this fixes their ordering, "a serialization"). The slave then reads the binlog and executes the statements in their binlog order.
In order to prevent data drift, serial execution of statements on the slave must have the same effect as concurrent execution of these statements on the master. In other words, transaction isolation on the master must be close to SERIALIZABLE
transaction isolation level (This is not a strict mathematical proof but shows the idea).
InnoDB achieves this by (almost) supporting SERIALIZABLE
transactional isolation level. It does so by supporting "Gap Locks". MyRocks doesn't support SERIALIZABLE
isolation, and it doesn't support gap locks.
Because of that, generally one cannot use MyRocks and statement-based replication.
If one tries updating a MyRocks table while having SBR on, they will get an error like this:
ERROR 4056 (HY000): Can't execute updates on master with binlog_format != ROW.
Can one still use SBR with MyRocks?
Yes. In many cases, database application runs a restricted set of SQL statements, and it's possible to prove that lack of Gap Lock support is not a problem and data skew will not occur.
In that case, one can set @@rocksdb_unsafe_for_binlog=1
and MyRocks will work with SBR. The user is however responsible for making sure their queries are not causing a data skew.
Read-Free Slave
TODO