Spec-Zone .ru
спецификации, руководства, описания, API
|
Если Вы следовали инструкциям, но Ваша установка репликации не работает, первое, что нужно сделать является проверкой журнал ошибок для сообщений. Много пользователей потеряли время, не делая это достаточно скоро после обнаружения с проблемами.
Если невозможно сказать из журнала ошибок, какова проблема была, попробуйте следующие методы:
Проверьте, что ведущему устройству включали двоичному файлу, регистрирующему,
выходя a SHOW MASTER STATUS
оператор. Если журналирование включается, Position
является ненулевым. Если
двоичное журналирование не включается, проверьте, что Вы выполняете ведущее устройство с --log-bin
опция.
Проверьте, что ведущее устройство и ведомое устройство оба были запущены с --server-id
опция и что Значение идентификатора уникально на каждом сервере.
Проверьте, что ведомое устройство работает. Использовать SHOW SLAVE STATUS
проверять ли Slave_IO_Running
и Slave_SQL_Running
значения -
оба Yes
. В противном случае проверьте опции, которые использовались,
запуская ведомый сервер. Например, --skip-slave-start
препятствует тому, чтобы ведомые потоки не
запустили до Вас проблему a START
SLAVE
оператор.
Если ведомое устройство работает, проверьте, установило ли оно соединение с ведущим
устройством. Использовать SHOW
PROCESSLIST
, найдите ввод-вывод и потоки SQL и проверьте их State
столбец, чтобы видеть, что они выводят на экран. См. Раздел 16.2.1, "Детали Реализации
Репликации". Если состояние потока ввода-вывода говорит Connecting to
master
, проверьте следующее:
Проверьте полномочия для пользователя, используемого для репликации на ведущем устройстве.
Проверьте, что имя хоста ведущего устройства корректно и что Вы
используете корректный порт, чтобы соединиться с ведущим устройством. Порт, используемый для
репликации, является тем же самым как использующийся для клиентских сетевых коммуникаций
(значение по умолчанию 3306
). Для имени хоста гарантируйте, что
имя решает к корректному IP-адресу.
Проверьте, что сети не были отключены на ведущем устройстве или ведомом
устройстве. Ищите skip-networking
опция в конфигурационном файле. Если
существующий, прокомментируйте это или удалите это.
Если у ведущего устройства есть брандмауэр или конфигурация фильтрации IP, гарантируйте, что сетевой порт, используемый для MySQL, не фильтруется.
Проверьте, что можно достигнуть ведущего устройства при использовании
ping
или traceroute
/tracert
достигнуть узла.
Если ведомое устройство работало ранее, но остановилось, причина обычно состоит в том, что некоторый оператор, который успешно выполнялся на ведущем устройстве, отказавшем на ведомом устройстве. Это никогда не должно происходить, если Вы взяли надлежащий снимок ведущего устройства, и никогда не изменяли данные на ведомом устройстве за пределами ведомого потока. Если ведомое устройство неожиданно останавливается, это - ошибка, или Вы встретились с одним из известных ограничений репликации, описанных в Разделе 16.4.1, "Функции репликации и Проблемы". Если это - ошибка, см. Раздел 16.4.5, "Как Сообщить об Ошибках Репликации или проблемах,", для инструкций по тому, как сообщить об этом.
Если оператор, который успешно выполнялся на ведущем устройстве, отказывается работать на ведомом устройстве, попробуйте следующую процедуру, если не выполнимо сделать полную пересинхронизацию базы данных, удаляя базы данных ведомого устройства и копируя новый снимок от ведущего устройства:
Определите, отличается ли таблица, на которую влияют, на ведомом
устройстве от основной таблицы. Попытайтесь понять, как это произошло. Затем сделайте
таблицу ведомого устройства идентичной ведущему устройству и работайте START SLAVE
.
Если бы предыдущий шаг не работает или не применяется, попытайтесь понять, было ли бы безопасно сделать обновление вручную (если нужно) и затем проигнорировать следующий оператор от ведущего устройства.
Если Вы решаете, что ведомое устройство может пропустить следующий оператор от ведущего устройства, сделайте следующие заявления:
mysql>SET GLOBAL sql_slave_skip_counter =
mysql>N
;START SLAVE;
Значение N
должен быть 1, если следующий
оператор от ведущего устройства не использует AUTO_INCREMENT
или LAST_INSERT_ID()
. Иначе, значение должно быть 2.
Причина использования значения 2 для операторов то использование AUTO_INCREMENT
или LAST_INSERT_ID()
это, они берут два события в двоичном журнале ведущего устройства.
См. также Раздел 13.4.2.4,"SET GLOBAL sql_slave_skip_counter
Синтаксис".
Если Вы уверены, что ведомое устройство, начатое отлично, синхронизировалось с ведущим устройством, и что никто не обновил таблицы, включенные за пределами ведомого потока, то по-видимому несоответствие является результатом ошибки. Если Вы выполняете новую версию MySQL, пожалуйста, сообщите о проблеме. Если Вы выполняете более старую версию, попытайтесь обновить до последнего производственного выпуска, чтобы определить, сохраняется ли проблема.