19.2.1.1 Advantages and Disadvantages of Statement-Based and Row-Based Replication — MySQL 8.4

19.2.1.1 Преимущества и недостатки репликации на основе операторов и на основе строк

Каждый формат двоичного протоколирования имеет свои преимущества и недостатки. Для большинства пользователей смешанный формат репликации должен обеспечить наилучшее сочетание целостности данных и производительности. Однако, если вы хотите воспользоваться функциями, специфичными для формата репликации на основе операторов или на основе строк при выполнении определенных задач, вы можете использовать информацию в этом разделе, который содержит краткое изложение их относительных преимуществ и недостатков, чтобы определить, какой из них лучше всего подходит для ваших потребностей.

Преимущества репликации на основе операторов

Доказанная технология.
Меньше данных записывается в файлы протокола. Когда обновления или удаления влияют на множество строк, это приводит к значительно меньшему объему памяти, требуемому для файлов протокола. Это также означает, что выполнение резервного копирования и восстановления из резервной копии может быть выполнено быстрее.
Файлы протокола содержат все операторы, которые внесли изменения, поэтому их можно использовать для аудита базы данных.

Недостатки репликации на основе операторов

Операторы, небезопасные для репликации на основе операторов (SBR). Не все операторы, изменяющие данные (такие как INSERT DELETE, UPDATE и REPLACE операторы) могут быть реплицированы с помощью репликации на основе операторов. Любое недетерминированное поведение трудно реплицировать при использовании репликации на основе операторов. Примеры таких операторов языка манипулирования данными (DML) включают следующее:
- Оператор, зависящий от загружаемой функции или хранимой программы, которая является недетерминированной, так как возвращаемое значение такой функции или хранимой программы зависит от факторов, отличных от параметров, предоставленных ей. (Репликация на основе строк, однако, просто реплицирует значение, возвращаемое функцией или хранимой программой, поэтому ее влияние на строки таблицы и данные одинаково как на источнике, так и на реплике). Дополнительную информацию см. в разделе 19.5.1.16 «Репликация вызванных функций».
- DELETE и UPDATE операторы, использующие клаузу LIMIT без клаузы ORDER BY, являются недетерминированными. См. раздел 19.5.1.18 «Репликация и LIMIT».
- Операторы чтения с блокировкой (SELECT ... FOR UPDATE и SELECT ... FOR SHARE), использующие параметры NOWAIT или SKIP LOCKED. См. Конкурентность чтения с блокировкой с помощью NOWAIT и SKIP LOCKED.
- Детерминированные загружаемые функции должны применяться на репликах.
- Операторы, использующие следующие функции, не могут быть корректно реплицированы с помощью репликации на основе операторов:
  - LOAD_FILE()
  - UUID(), UUID_SHORT()
  - USER()
  - FOUND_ROWS()
  - SYSDATE() (если оба источник и реплика запущены с параметром --sysdate-is-now)
  - GET_LOCK()
  - IS_FREE_LOCK()
  - IS_USED_LOCK()
  - RAND()
  - RELEASE_LOCK()
  - SOURCE_POS_WAIT()
  - SLEEP()
  - VERSION()
  Однако все остальные функции реплицируются корректно с помощью репликации на основе операторов, включая NOW() и так далее.
  
  Дополнительную информацию см. в разделе 19.5.1.14 «Репликация и системные функции».
Операторы, которые не могут быть корректно реплицированы с помощью репликации на основе операторов, регистрируются с предупреждением, как показано здесь:
```
[Warning] Statement is not safe to log in statement format.
```
Аналогичное предупреждение также выдается клиенту в таких случаях. Клиент может отобразить его с помощью SHOW WARNINGS.
INSERT ... SELECT требует большего числа блокировок на уровне строк, чем при репликации на основе строк.
UPDATE операторы, требующие сканирования таблицы (потому что индекс не используется в клаузе WHERE), должны заблокировать большее количество строк, чем при репликации на основе строк.
Для InnoDB: оператор INSERT, использующий AUTO_INCREMENT блокирует другие неконфликтующие операторы INSERT.
Для сложных операторов оператор должен быть оценен и выполнен на реплике перед обновлением или вставкой строк. При репликации на основе строк реплике нужно только изменить затронутые строки, а не выполнять весь оператор.
Если при выполнении, особенно сложных операторов, возникает ошибка на реплике, репликация на основе операторов может со временем медленно увеличивать погрешность по затронутым строкам. См. раздел 19.5.1.29 «Ошибки репликации на реплике».
Хранимые функции выполняются с тем же значением NOW(), что и вызывающий оператор. Однако это не относится к хранимым процедурам.
Детерминированные загружаемые функции должны применяться на репликах.
Определения таблиц должны быть (почти) идентичными на источнике и реплике. См. раздел 19.5.1.9 «Репликация с разными определениями таблиц на источнике и реплике» для получения дополнительной информации.
Операции DML, которые считывают данные из таблиц MySQL grant (через список объединения или подзапрос), но не изменяют их, выполняются как операции чтения без блокировки в таблицах MySQL grant и поэтому не подходят для репликации на основе операторов. Дополнительную информацию см. в разделе «Конкурентность таблиц grant».

Преимущества репликации на основе строк

Все изменения могут быть воспроизведены. Это наиболее безопасный способ воспроизведения.

Примечание

Заявления, обновляющие информацию в схеме системы mysql, такие как GRANT, REVOKE, а также манипуляции триггерами, хранимыми процедурами (включая хранимые процедуры) и представлениями, дублируются на реплики с помощью репликации на основе заявлений.

Для заявлений, таких как CREATE TABLE ... SELECT, из определения таблицы генерируется заявление CREATE и дублируется в формате на основе заявлений, а вставки строк дублируются в формате на основе строк.
Для следующих типов заявлений требуется меньше блокировок строк на источнике, что обеспечивает более высокую конкурентность:
- INSERT ... SELECT
- Заявления INSERT с AUTO_INCREMENT
- Заявления UPDATE или DELETE с WHERE условиями, которые не используют ключи или не изменяют большинство проверяемых строк.
Для любого заявления INSERT, UPDATE или DELETE требуется меньше блокировок строк на реплике.

Недостатки репликации на основе строк

RBR может генерировать больше данных, которые необходимо записать в журнал. Для дублирования DML-заявления (например, UPDATE или DELETE ), репликация на основе заявлений записывает только само заявление в двоичный журнал. В отличие от этого, репликация на основе строк записывает каждую измененную строку в двоичный журнал. Если заявление изменяет много строк, репликация на основе строк может записать значительно больше данных в двоичный журнал; это верно даже для заявлений, которые отменены. Это также означает, что создание и восстановление резервной копии может занять больше времени. Кроме того, двоичный журнал блокируется на более длительное время для записи данных, что может привести к проблемам с конкурентностью. Используйте binlog_row_image=minimal, чтобы значительно уменьшить этот недостаток.
Детерминированные загружаемые функции, которые генерируют большие значения BLOB, требуют больше времени для дублирования с помощью репликации на основе строк, чем с репликацией на основе заявлений. Это связано с тем, что значение столбца BLOB записывается в журнал, а не само заявление, генерирующее данные.
На реплике невозможно увидеть, какие заявления были получены от источника и выполнены. Однако вы можете увидеть, какие данные были изменены, используя mysqlbinlog с параметрами --base64-output=DECODE-ROWS и --verbose.

В качестве альтернативы, используйте переменную binlog_rows_query_log_events, которая, если она включена, добавляет событие Rows_query с заявлением к выводу mysqlbinlog при использовании параметра -vv.
Для таблиц, использующих движок хранения MyISAM, для заявлений INSERT при применении их как событий на основе строк в двоичный журнал требуется более сильная блокировка на реплике, чем при применении их как заявлений. Это означает, что одновременные вставки в таблицы MyISAM не поддерживаются при использовании репликации на основе строк.