Spec-Zone .ru
спецификации, руководства, описания, API

16.2.3. Как Серверы Оценивают Правила Фильтрации Репликации

16.2.3.1. Оценка Репликации На уровне базы данных и Двоичных Опций Журналирования
16.2.3.2. Оценка Опций Репликации На уровне таблицы
16.2.3.3. Приложение Правила репликации

Если главный сервер не пишет оператор в свой двоичный журнал, оператор не тиражируется. Если сервер действительно регистрирует оператор, оператор отправляется всем ведомым устройствам, и каждое ведомое устройство определяет, выполнить ли это или проигнорировать это.

На ведущем устройстве можно управлять который базы данных зарегистрировать изменения для при использовании --binlog-do-db и --binlog-ignore-db опции, чтобы управлять двоичным журналированием. Для описания правил, что использование серверов в оценке этих опций, см. Раздел 16.2.3.1, "Оценка Репликации На уровне базы данных и Двоичных Опций Журналирования". Недопустимо использовать эти опции, чтобы управлять, какие базы данных и таблицы тиражируются. Вместо этого используйте фильтрацию на ведомом устройстве, чтобы управлять событиями, которые выполняются на ведомом устройстве.

На ведомой стороне решения о том, выполнить ли или проигнорировать операторы, полученные от ведущего устройства, принимаются согласно --replicate-* опции, с которых было запущено ведомое устройство. (См. Раздел 16.1.4, "Репликация и Двоичные Опции Журналирования и Переменные".)

В самом простом случае, когда есть нет --replicate-* опции, ведомое устройство выполняет все операторы, которые оно получает от ведущего устройства. Иначе, результат зависит от определенных данных опций.

Опции на уровне базы данных (--replicate-do-db, --replicate-ignore-db) проверяются сначала; см. Раздел 16.2.3.1, "Оценка Репликации На уровне базы данных и Двоичных Опций Журналирования", для описания этого процесса. Если никакие соответствующие опции на уровне базы данных не находятся, проверка опции продолжается к любым опциям на уровне таблицы, которые могут использоваться, как обсуждено в Разделе 16.2.3.2, "Оценка Опций Репликации На уровне таблицы".

Для операторов, влияющих на базы данных только (то есть, CREATE DATABASE, DROP DATABASE, и ALTER DATABASE), опции на уровне базы данных всегда имеют приоритет по любому --replicate-wild-do-table опции. Другими словами, для таких операторов, --replicate-wild-do-table опции проверяются, если и только если нет никаких опций на уровне базы данных, которые применяются. Это - изменение в поведении от предыдущих версий MySQL, где оператор CREATE DATABASE dbx не был тиражирован, если ведомое устройство было запущено с --replicate-do-db=dbx --replicate-wild-do-table=db%.t1. (Ошибка #46110)

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

Если любой --replicate-rewrite-db опции были определены, они применяются перед --replicate-* тестируются фильтрующие правила.

Отметить

В MySQL 5.6 все опции фильтрации репликации следуют за теми же самыми правилами для чувствительности к регистру, которые применяются к именам баз данных и таблиц в другом месте в сервере MySQL, включая эффекты lower_case_table_names системная переменная.

Это - изменение от предыдущих версий MySQL. (Ошибка #51639)