MyRocks and Replication

You are viewing an old version of this article. View the current version here.

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

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.