16.2.1.1 Advantages and Disadvantages of Statement-Based and Row-Based Replication — MySQL 5.7

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

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

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

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

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

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

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

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

Примечание

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