mk-table-sync в сценарии "ведущий-ведомый": изменения, не реплицированные на ведомый
Я использую mk-table-sync для синхронизации таблиц от мастера к подчиненному на MySQL 5.1. К сожалению, хотя различия правильно обнаруживаются, модификации, выполненные на главном устройстве (DELETE,REPLACE,ecc.), По-видимому, не распространяются на ведомое устройство. SHOW SLAVE STATUS не выявляет проблем с подключением.
В основном, делать
mk-table-sync -v --execute --databases=forum --sync-to-master
h=localhost,D=forum,t=user
# Syncing D=forum,h=localhost,t=user
# DELETE REPLACE INSERT UPDATE ALGORITHM START END EXIT DATABASE.TABLE
# 0 7 0 0 Chunk 14:35:00 14:35:01 2 forum.user
неоднократно дает всегда одни и те же результаты, без фактического изменения ведомого.
Вход на раб:
Войдите в мастер:
То же самое касается УДАЛЕНИЙ, выполненных на ведущем устройстве, и для каждой другой таблицы в реплицированной базе данных.
Есть идеи?
заранее спасибо
2 ответа
Честно говоря, я никогда не доверял параметру --execute для mk-table-sync. Я всегда использую --print вместо.
Замени это
mk-table-sync -v --execute --databases=forum --sync-to-master h=localhost,D=forum,t=user
с этим, если у вас включена двоичная регистрация
echo "SET SQL_LOG_BIN=0;" > DBChanges.sql
mk-table-sync -v --print --databases=forum --sync-to-master h=localhost,D=forum,t=user >> DBChanges.sql
или это если ведомый не имеет бинарной регистрации
mk-table-sync -v --print --databases=forum --sync-to-master h=localhost,D=forum,t=user > DBChanges.sql
Таким образом, вы можете увидеть фактический SQL для безопасного запуска на ведомом устройстве.
ОБНОВЛЕНИЕ 2011-05-31 12:57
"Интересно. Поправьте меня, если я ошибаюсь, но не следует ли распространять запросы, выполняемые на ведущем устройстве, на подчиненное устройство посредством репликации? Я не совсем понимаю, почему этого не происходит"
Это справедливый вопрос. Тем не менее, подумайте о том, как работает MySQL Replication. Когда оператор SQL завершен на главном сервере, он записывается в двоичные журналы мастера. Поток ввода / вывода подчиненного устройства считывает любые новые записи в двоичных журналах ведущего устройства и добавляет их в последний из журналов ретрансляции подчиненного устройства. Поток SQL ведомого считывает записи журнала ретрансляции как очередь FIFO и обрабатывает операторы SQL в порядке их записи. Если ведомое устройство имеет log-slave-updates и log-bin в своей конфигурации, то подтверждение SQL по завершении будет записано в двоичные журналы ведомого устройства.
Достаточно небольшой разговор о репликации MySQL.
Теперь, почему хозяин не должен копировать рабов???
Вот несколько возможностей для изучения:
ВОЗМОЖНОСТЬ № 1: Задержка в сети, приводящая к тому, что записи в двоичном журнале от ведущего устройства не распространяются своевременно или совсем не распространяются на журналы ретрансляции ведомого устройства.
ВОЗМОЖНОСТЬ # 2: пакеты MySQL слишком малы и ошибки игнорируются. Это может произойти только в следующем сценарии: max_allowed_packet в ведущем устройстве больше, чем max_allowed_packet в ведомом устройстве. Это обычно останавливало бы репликацию на своем пути. Если вы пропускаете все ведомые ошибки (если у вас есть / slave-skip-errors = all в /etc/my.cnf), то в этом уникальном сценарии можно игнорировать различные виды обычных данных.
ВОЗМОЖНОСТЬ № 3: Конфигурация для пропуска любой ошибки дублирования ключа в потоке SQL ведомого
[mysqld]
slave-skip-errors=1062 (skips duplicate key errors)
ВОЗМОЖНОСТЬ № 4: Конфигурация для пропуска любой ошибки SQL в потоке SQL ведомого
[mysqld]
slave-skip-errors=all (skips every SQL error under the sun)
ВОЗМОЖНОСТЬ № 5: Наличие потока ввода-вывода подчиненного просто умирает, не сообщая mysqld. Это может случиться Простая коррекция? Выполните следующие действия, чтобы восстановить подчиненный поток ввода-вывода:
STOP SLAVE IO_THREAD;
START SLAVE IO_THREAD;
ВОЗМОЖНОСТЬ № 6: Неправильная комбинация replicate-do-db и replicate-ignore-db в /etc/my.cnf (Отказ от ответственности: это строго мое мнение)
Некоторые смешивают оба параметра в /etc/my.cnf и ничего об этом не думают. ИМХО, эти варианты должны быть взаимоисключающими. Вы следуете логике фильтрации данных или фильтрации данных в ведомом устройстве. Их не следует использовать вместе, поскольку вы можете получить ложные результаты репликации. Либо данные должны быть там, либо нет, НЕ данные должны быть там и нет.
Вполне возможно, что вы используете версию mk-table-sync, которая не устанавливает формат binlog в STATEMENT, поэтому на самом деле не изменяет какие-либо данные на ведущем устройстве (как спроектировано) и, таким образом, ничего не попадает в двоичный журнал.