19.2.5.1 Evaluation of Database-Level Replication and Binary Logging Options — MySQL 9.2

19.2.5.1 Оценка параметров репликации на уровне базы данных и бинарного логгирования

При оценке параметров репликации реплика сначала проверяет, существуют ли параметры --replicate-do-db или --replicate-ignore-db. При использовании --binlog-do-db или --binlog-ignore-db, процесс аналогичен, но параметры проверяются на источнике.

База данных, проверяемая на соответствие, зависит от формата бинарного лога обрабатываемого оператора. Если оператор был записан в формате строк, то проверяется база данных, в которой будут изменены данные. Если оператор был записан в формате оператора, то используется база данных по умолчанию (указанная с помощью оператора USE).

Примечание

Только операторы DML могут быть записаны в формате строк. Операторы DDL всегда записываются как операторы, даже когда binlog_format=ROW. Поэтому все операторы DDL всегда фильтруются по правилам репликации на основе операторов. Это означает, что для применения оператора DDL необходимо явно выбрать базу данных по умолчанию с помощью оператора USE.

Для репликации шаги описаны здесь:

Какой формат логирования используется?
- ОПЕРАТОР. Проверить базу данных по умолчанию.
- СТРОКА. Проверить базу данных, затронутую изменениями.
Существуют ли какие-либо параметры --replicate-do-db?
- Да. Соответствует ли база данных какой-либо из них?
  - Да. Перейти к шагу 4.
  - Нет. Пропустить обновление и выйти.
- Нет. Перейти к шагу 3.
Существуют ли какие-либо параметры --replicate-ignore-db?
- Да. Соответствует ли база данных какой-либо из них?
  - Да. Пропустить обновление и выйти.
  - Нет. Перейти к шагу 4.
- Нет. Перейти к шагу 4.
Продолжить проверку параметров репликации на уровне таблиц, если они есть. Описание того, как проверяются эти параметры, см. в разделе 19.2.5.2, «Оценка параметров репликации на уровне таблиц».

Важно

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

Для бинарного протоколирования шаги приведены здесь:

Существуют ли какие-либо параметры --binlog-do-db или --binlog-ignore-db?
- Да. Перейти к шагу 2.
- Нет. Записать оператор в журнал и выйти.
Существует ли база данных по умолчанию (выбрана ли какая-либо база данных с помощью оператора USE)?
- Да. Перейти к шагу 3.
- Нет. Пропустить оператор и выйти.
Существует база данных по умолчанию. Существуют ли какие-либо параметры --binlog-do-db?
- Да. Соответствуют ли какие-либо из них базе данных?
  - Да. Записать оператор в журнал и выйти.
  - Нет. Пропустить оператор и выйти.
- Нет. Перейти к шагу 4.
Соответствуют ли какие-либо параметры --binlog-ignore-db базе данных?
- Да. Пропустить оператор и выйти.
- Нет. Записать оператор в журнал и выйти.

Важно

Для логирования на основе операторов правила, приведенные для операторов CREATE DATABASE, ALTER DATABASE и DROP DATABASE, имеют исключение. В этих случаях база данных, которая создается, изменяется или удаляется, заменяет базу данных по умолчанию при определении, следует ли записывать или пропускать обновления.

--binlog-do-db иногда может означать “пропустить другие базы данных”. Например, при использовании логирования на основе операторов сервер, работающий только с --binlog-do-db=sales, не записывает в бинарный журнал операторы, для которых база данных по умолчанию отличается от sales. При использовании строчного логирования с тем же параметром сервер записывает только те обновления, которые изменяют данные в sales.