Выборочное пропускание репликации событий бинарного журнала

Обычно все изменения, которые регистрируются как события в бинарном журнале, также реплицируются на все реплики (хотя всё ещё подлежат фильтрации параметрами replicate-do-db, replicate-ignore-db и аналогичными). Однако иногда может потребоваться, чтобы некоторые события записывались в бинарный журнал, но не реплицировались на все или на подмножество реплик, где различие между событиями, которые следует реплицировать, или нет, находится под контролем приложения, производящего изменения.

Это может быть полезно, если приложение выполняет репликацию вне сервера, за пределами встроенной репликации, или если оно имеет данные, которые по каким-либо причинам не должны реплицироваться.

Это возможно с помощью следующих системных переменных.

Переменная сессии первичного сервера: skip_replication

Когда переменная skip_replication установлена в значение true, изменения записываются в бинарный журнал со флагом @@skip_replication. Такие события не будут реплицироваться репликами, работающими с --replicate-events-marked-for-skip значением, отличным от его значения по умолчанию REPLICATE.

Опция skip_replication действует только в том случае, если включена запись в бинарный журнал и sql_log_bin установлено в true.

Попытка изменить @@skip_replication в середине транзакции завершится ошибкой; это делается для того, чтобы избежать репликации только половины транзакции, в то время как другая половина не реплицируется. Убедитесь, что вы завершите любую текущую транзакцию с COMMIT/ROLLBACK перед изменением переменной.

Параметр реплики: --replicate-events-marked-for-skip

Параметр replicate_events_marked_for_skip указывает реплике, нужно ли реплицировать события, помеченные флагом @@skip_replication. Значение по умолчанию — REPLICATE, чтобы гарантировать, что все изменения реплицируются на реплику. Если установить в FILTER_ON_SLAVE, события, помеченные таким образом, будут пропущены на реплике и не будут реплицированы. Если установить в FILTER_ON_MASTER, фильтрация будет выполнена на первичном сервере, экономя сетевую пропускную способность, так как события вообще не будут получены репликой.

Когда события фильтруются из-за @@skip_replication, фильтрация происходит на стороне первичного сервера; другими словами, событие никогда не отправляется реплике. Если множество событий фильтруется таким образом, реплика может долгое время не получать никаких событий от первичного сервера. Это само по себе не проблема, но следует помнить об этом, когда запрашиваете события у реплики, которые были отфильтрованы. Например, START SLAVE UNTIL <some position> остановится, когда будет встречено первое событие, которое не фильтруется, в указанной позиции или дальше. Если событие в указанной позиции отфильтровано, то поток реплики остановится только при встрече следующего неотфильтрованного события. По сути, если событие отфильтровано, то для реплики кажется, что оно никогда не было записано в бинарный журнал на первичном сервере.

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

Переменная сессии @@skip_replication может быть изменена без специальных привилегий. Это позволяет обычным приложениям управлять ею без необходимости в привилегиях SUPER. Но следует помнить об этом, когда используются реплики с --replicate-events-marked-for-skip значением, отличным от REPLICATE, так как это позволяет любому подключению вносить изменения, которые не реплицируются.

skip_replication и sql_log_bin

@@sql_log_bin и @@skip_replication связаны между собой, поскольку оба могут использоваться для предотвращения репликации изменения на первичном сервере на реплику. Разница заключается в том, что при использовании @@skip_replication, изменения всё ещё записываются в бинарный журнал, а репликация событий пропускается только на тех репликах, которые явно настроены на это, с --replicate-events-marked-for-skip значением, отличным от REPLICATE. При использовании @@sql_log_bin, события не записываются в бинарный журнал и не реплицируются ни на какой реплике.

skip_replication и бинарный журнал

Когда события в бинарном журнале помечены флагом @@skip_replication, флаг будет сохранён, если события экспортированы программой mariadb-binlog и повторно применены к серверу с помощью программы mariadb client. Аналогично, инструкция BINLOG сохранит флаг при повторном воспроизведении события. И реплика, работающая с --log-slave-updates и не фильтрующая события (--replicate-events-marked-for-skip=REPLICATE), также сохранит флаг в событиях, записанных в бинарный журнал на реплике.

См. также

• Использование SQL_SLAVE_SKIP_COUNTER - Как пропустить определённое количество событий на реплике