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

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

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

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

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

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

Операторы, небезопасные для SBR. Не все операторы, которые изменяют данные (например, INSERT DELETE, UPDATE и REPLACE операторы) могут быть реплицированы с помощью репликации на основе операторов. Любое недетерминированное поведение сложно реплицировать при использовании репликации на основе операторов. Примеры таких операторов языка манипулирования данными (DML) включают следующее:
- Оператор, зависящий от загружаемой функции или хранимой программы, которая является не детерминированной, так как возвращаемое значение такой функции или хранимой программы зависит от факторов, помимо параметров, предоставленных ей. (Репликация на основе строк, однако, просто реплицирует возвращаемое значение функции или хранимой программы, поэтому ее влияние на строки таблиц и данные одинаково как на источнике, так и на реплике.) Дополнительную информацию см. в Разделе 19.5.1.16, «Репликация вызываемых функций».
- DELETE и UPDATE операторы, использующие клаузу LIMIT без клаузы ORDER BY, являются не детерминированными. См. Раздел 19.5.1.19, «Репликация и 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.30, «Ошибки реплики во время репликации».
Хранимые функции выполняются с тем же значением NOW(), что и вызывающий оператор. Однако это не относится к хранимым процедурам.
Загружаемые функции должны быть применены на репликах.
Определения таблиц должны быть (почти) идентичными на источнике и реплике. См. Раздел 19.5.1.9, «Репликация с различными определениями таблиц на источнике и реплике» для получения дополнительной информации.
Операции DML, которые считывают данные из таблиц разрешений MySQL (через список присоединения или подзапрос), но не изменяют их, выполняются как неблокирующие чтения в таблицах разрешений MySQL и, следовательно, не безопасны для репликации на основе операторов. Дополнительную информацию см. в Конкурентности таблиц разрешений.

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

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

Примечание

Заявления, обновляющие информацию в схеме системы 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 не поддерживаются при использовании репликации на основе строк.