Row Locking

Row Locks

MyRocks supports both shared and exclusive row locks. 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 an exclusive row lock, it can block other mysql clients from modifying 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 unique_check=0 for a particular client. This can cause an increase in performance for clients that are bulk loading a new table. Any duplicate keys inserted while unique checks is disabled will result in the conflicting row being updated. Use of this option should be cautions as 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.