Row Locking

Row Locks

Only exclusive row locks are supported by MyRocks. MyRocks uses the lock manager from the RocksDB library to support locking rows during updates within a transaction. INSERT and UPDATE statements automatically acquire exclusive row locks. These locks can also be acquired via

• SELECT ... FOR UPDATE
• SELECT ... LOCK IN SHARE MODE

Once a mysql client acquires a row lock, it can block other mysql clients from modifying the row. However, there are some differences in record locking behavior from other storage engines. Since only exclusive locks are supported, two clients trying to acquire read locks via SELECT ... LOCK IN SHARE MODE will result in one client failing to lock the row.

The locks are held for the duration of the transaction. Once the transaction is committed or rolled back, the locks are all released.

Skipping Row Locks

Row locking and unique key checking can be disabled via the system variable rocksdb_skip_unique_check for a particular client. This can be an increase in performance for clients that are bulk loading a new table and can guarantee there are no conflicts between the data being inserted and the existing data within the database. However, it can result in corrupted tables and indexes if used improperly.

Gap Locks

There is currently no support for gap locking within MyRocks. Transactions that depend on gap locking to support repeatable read isolation level when running on MyRocks can result in master and slave mismatches for statement-based replication. The system variable gap_lock_raise_error can be set to detect when gap locks are being requested on existing transactions and they can be logged to gap_lock_write_log file.

For replication, if the master server is using the MyRocks storage engine, it requires row based replication to be enabled.