Я использую mk-table-sync для синхронизации таблиц от ведущего к ведомому на mysql 5.1. К сожалению, хотя различия обнаруживаются правильно, модификации, сделанные на главном устройстве (DELETE, REPLACE и т. Д.), Похоже, не распространяются на подчиненное устройство. 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
многократно дает всегда одни и те же результаты без фактического изменения ведомого устройства.
Войдите на раб:
Войдите в мастер:
То же самое касается DELETE, выполняемых на главном сервере, и для каждой другой таблицы в реплицированной базе данных.
Любые идеи?
заранее спасибо
Честно говоря, я никогда не доверял параметру --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. Когда оператор SQL завершается на ведущем устройстве, он записывается в двоичные журналы ведущего устройства. Поток ввода-вывода подчиненного устройства считывает любые новые записи в двоичных журналах главного устройства и добавляет их в последний из журналов реле подчиненного устройства. Поток SQL подчиненного устройства считывает записи журнала реле как очередь FIFO и обрабатывает операторы SQL в порядке их записи. Если ведомое устройство имеет в своей конфигурации log-slave-updates и log-bin, после завершения SQL-запрос будет записан в двоичные журналы ведомого.
Хватит болтать о репликации MySQL.
Теперь, почему мастер не реплицирует на подчиненное устройство ???
Вот несколько возможностей для изучения:
ВОЗМОЖНОСТЬ # 1 : Сетевая задержка, из-за которой записи binlog от ведущего устройства не распространяются в журналы реле ведомого устройства своевременно или не распространяются вообще.
ВОЗМОЖНОСТЬ №2 : Пакеты MySQL слишком малы, и ошибки игнорируются. Это могло произойти только в следующем сценарии: max_allowed_packet в главном устройстве больше, чем max_allowed_packet в подчиненном устройстве. Обычно это останавливает репликацию на месте. Если вы пропускаете все ошибки подчиненного устройства (если у вас есть slave-skip-errors = all в /etc/my.cnf), то в этом уникальном сценарии можно игнорировать различные типы обычных данных.
ВОЗМОЖНОСТЬ # 3 : Config пропустить любую ошибку дублирования ключа в потоке SQL подчиненного устройства
[mysqld]
slave-skip-errors=1062 (skips duplicate key errors)
ВОЗМОЖНОСТЬ # 4 : Config пропустить любую ошибку 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, поэтому на самом деле не меняет никаких данных на главном сервере (как задумано), и, таким образом, ничего не попадает в двоичный журнал.