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

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

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

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

Примечание

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

Для репликации этапы, вовлеченные в процесс, приведены ниже:

Какой формат журналирования используется?
- ОПЕРАТОР. Проверить базу данных по умолчанию.
- СТРОКА. Проверить базу данных, затронутую изменениями.
Существуют ли параметры --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.