MyRocks и репликация

Подробности о том, как MyRocks работает с репликацией.

MyRocks и репликация на основе операторов

Репликация на основе операторов (SBR) работает следующим образом: операторы SQL выполняются на мастер-сервере (возможно, параллельно). Они записываются в журнал бинарных логов (это фиксирует их порядок, «сериализация»). Затем раб-сервер считывает журнал бинарных логов и выполняет операторы в соответствии с порядком в журнале.

Для предотвращения смещения данных последовательное выполнение операторов на раб-сервере должно давать тот же результат, что и параллельное выполнение этих операторов на мастер-сервере. Другими словами, уровень изоляции транзакций на мастер-сервере должен быть близок к SERIALIZABLE уровню изоляции транзакций (Это не строгое математическое доказательство, а демонстрация идеи).

InnoDB достигает этого, (почти) поддерживая SERIALIZABLE уровень изоляции транзакций. Это делается с помощью «блокировок разрывов» (Gap Locks). MyRocks не поддерживает SERIALIZABLE изоляцию, и он не поддерживает блокировки разрывов.

Из-за этого, как правило, нельзя использовать MyRocks и репликацию на основе операторов.

Обновление таблицы MyRocks при включённой SBR приведёт к ошибке следующего вида:

ERROR 4056 (HY000): Can't execute updates on master with binlog_format != ROW.

Можно ли всё ещё использовать SBR с MyRocks?

Да. Во многих случаях базы данных работают со строгим набором операторов SQL, и можно доказать, что отсутствие поддержки блокировок разрывов не является проблемой, и искажения данных не произойдёт.

В этом случае можно установить @@rocksdb_unsafe_for_binlog=1 и MyRocks будет работать с SBR. Однако пользователь несёт ответственность за обеспечение того, чтобы его запросы не приводили к искажению данных.

Раб-сервер без чтения

TODO

Отличия от MyRocks из исходного кода

MyRocks из исходного кода (то есть, ветка MySQL Facebook) имеет ряд уникальных улучшений репликации. Они доступны в версии MyRocks из исходного кода, но не в версии MyRocks от MariaDB.

• Репликация без чтения (см. https://github.com/facebook/mysql-5.6/wiki/Read-Free-Replication) TODO

• <<unique_check_lag_threshold>>. Это функция FB/MySQL-5.6, где уникальные проверки отключаются, если задержка репликации превышает определённый порог.
• <<slave_gtid_info=OPTIMIZED>>. Говорится, что это:

<<quote>>
"Whether SQL threads update mysql.slave_gtid_info table. If this value "
"is OPTIMIZED, updating the table is done inside storage engines to "
"avoid MySQL layer's performance overhead",
<</quote>>