16.1.2.1. Преимущества и Недостатки Основанных на операторе и Строки-BasedReplication

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

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

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

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

Операторы, которые опасны для SBR. Не все операторы, которые изменяют данные (такие как INSERT DELETE, UPDATE, и REPLACE операторы), может быть тиражирован, используя основанную на операторе репликацию. Любое недетерминированное поведение трудно тиражировать при использовании основанной на операторе репликации. Примеры такого DML (Язык Модификации данных) операторы включают следующее:
- Оператор, который зависит от UDF или сохраненной программы, которая недетерминирована, начиная со значения, возвращенного таким UDF или сохраненной программой, или зависит от факторов кроме параметров, предоставленных этому. (Построчная репликация, однако, просто тиражирует значение, возвращенное UDF или сохраненной программой, таким образом, ее эффект на строки таблицы и данные является тем же самым и на ведущем устройстве и на ведомом устройстве.) См. Раздел 16.4.1.11, "Репликация Вызванных Функций", для получения дополнительной информации.
- DELETE и UPDATE операторы то использование a LIMIT пункт без ORDER BY недетерминированы. См. Раздел 16.4.1.16, "Репликация и 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, "Репликация и Системные функции".
Операторы, которые не могут быть тиражированы, правильно используя основанную на операторе репликацию, регистрируются с предупреждением как один показанный здесь:
```
090213 16:58:54 [Warning] Statement is not safe to log in statement format.
```
Подобное предупреждение также выпускается клиенту в таких случаях. Клиент может вывести на экран это использование SHOW WARNINGS.
INSERT ... SELECT требует большего числа блокировок на уровне строки чем с построчной репликацией.
UPDATE операторы, которые требуют сканирования таблицы (потому что не индексируют, используется в WHERE пункт), должен заблокировать большее число строк чем с построчной репликацией.
Для InnoDB: INSERT оператор, который использует AUTO_INCREMENT блокирует другой неконфликт INSERT операторы.
Для сложных операторов оператор должен быть оценен и выполнен на ведомом устройстве прежде, чем строки будут обновлены или вставлены. С построчной репликацией ведомое устройство только должно изменить строки, на которые влияют, не выполняют полный оператор.
Если есть ошибка в оценке на ведомом устройстве, особенно выполняя сложные операторы, основанная на операторе репликация может медленно увеличивать предел погрешности через строки, на которые влияют, в течение долгого времени. См. Раздел 16.4.1.26, "Ведомые Ошибки Во время Репликации".
Сохраненные функции выполняются с тем же самым NOW() оцените как оператор вызова. Однако, это не верно для хранимых процедур.
Детерминированный UDFs должен быть применен на ведомые устройства.
Табличные определения должны быть (почти) идентичными на ведущем устройстве и ведомом устройстве. См. Раздел 16.4.1.9, "Репликация с Отличающимися Табличными Определениями на Ведущем устройстве и Ведомом устройстве", для получения дополнительной информации.

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

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

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

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

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

RBR имеет тенденцию генерировать больше данных, которые должны регистрироваться. Тиражировать оператор DML (такой как UPDATE или DELETE оператор), основанная на операторе репликация пишет только оператор в двоичный журнал. В отличие от этого, построчная репликация пишет каждую измененную строку в двоичный журнал. Если оператор изменяет много строк, построчная репликация может записать значительно больше данных в двоичный журнал; это - истина даже для операторов, которые откатываются. Это также означает, что взятие и восстановление от резервного копирования могут потребовать большего количества времени. Кроме того, двоичный журнал блокируется в течение более длительного времени, чтобы записать данные, которые могут вызвать проблемы параллелизма.
Детерминированные UDFs, которые генерируют большой BLOB значения занимают больше времени, чтобы тиражироваться с построчной репликацией чем с основанной на операторе репликацией. Это то, потому что BLOB значение столбца регистрируется, а не оператор, генерирующий данные.
Невозможно исследовать журналы, чтобы видеть, какие операторы выполнялись, и при этом невозможно видеть на ведомом устройстве, какие операторы были получены от ведущего устройства и выполнены.

Однако, можно видеть, какие данные были изменены, используя mysqlbinlog с опциями --base64-output=DECODE-ROWS и --verbose.
Для таблиц, используя MyISAM механизм хранения, более сильная блокировка требуется на ведомом устройстве для INSERT операторы, применяя их как основанные на строке события к двоичному журналу, применяя их как операторы. Это означает что параллельные вставки на MyISAM таблицы не поддерживаются при использовании построчной репликации.