Репликация MySQL не выполняет обновления в binlog
У меня есть несколько серверов mysql, работающих под управлением версии 5.1.63, и во время выполнения некоторых запросов к ведомому устройству ранее на этой неделе я заметил некоторые данные о ведомом устройстве, которые должны были быть удалены с помощью инструкции update на ведущем устройстве.
мои первые мысли были:
- кто-то из команды обновлял раба, который я с тех пор опроверг
- что обновляемый столбец изменился
Итак, я исследовал, запустив mysql показывает запрос состояния "таблица". Это было запущено против тестовой базы данных на каждом из серверов, чтобы увидеть, какова длина данных, во многих случаях она показывала мне, что длина данных отличается между серверами, но на глазном яблоке посмотрите на данные, которые я мог видеть, данные были одинаковыми, поэтому я не мог использовать этот метод, чтобы увидеть, есть ли какие-либо различия, поскольку он, похоже, склонен к ошибке.
затем я запустил простой (по всем dbs) счетчик строк для каждой таблицы, чтобы подтвердить, что количество строк было одинаковым - Это было.
затем я начал искать в журналах bin для репликации. Я мог видеть инструкции update, которые должны были работать четко видны в журналах, но обновление никогда не выполнялось.
Что мне нужно знать это:
- нарушается репликация? Я предполагаю, что это
- если я создам новые подчиненные серверы, я столкнусь с той же проблемой?
- как узнать степень проблемы на моих серверах?
любая помощь оцененный.
3 ответов
Если вы используете репликацию на основе операторов, то легко можно получить разные результаты на master и slave из-за плохо построенных инструкций INSERT.
INSERT SELECT без ORDER BY, или где ORDER BY может оставить недетерминированные результаты, приведет к тому, что рабы будут отличаться от master.
с сайта MySQL http://dev.mysql.com/doc/refman/5.1/en/insert-select.html
порядок, в котором строки возвращается инструкцией SELECT без Предложение ORDER BY не определено. Это означает, что при использовании репликация, нет никакой гарантии, что такой SELECT возвращает строки в и на ведущем устройстве и ведомом устройстве, это может привести к несоответствия между ними. Чтобы предотвратить это, вы всегда следует писать INSERT ... Выберите операторы, которые должны быть реплицируется как INSERT ... ВЫБИРАТЬ... Порядок по колонкам. Выбор столбец не имеет значения, пока тот же порядок для возвращение ряда применяется как хозяин и раб. См. также раздел 16.4.1.15, "репликация" и "предел".
Если это произошло, то ваши реплики разошлись, и единственный безопасный способ вернуть их в строй-это перестроить их из недавней резервной копии главной БД. Худшая часть этого-ошибка может никогда не привести к сбою репликации, но результаты несовместимы. Обычно репликация завершается неудачно, если инструкция UPDATE или DELETE влияет на разное количество строк, чем на master, это сбивает с толку, поскольку это не было обновление, которое на самом деле вызвало ошибку, и единственный способ исправить проблему-проверить каждый запрос вставки в базе кода!
сведения о статусе из information_schema, которая собирает данные из статистики баз данных для экземпляра Mysql, и она никогда не оставалась прежней при каждом выполнении. Его можно рассматривать как грубую оценку размеров данных в байтах, но никогда не точное значение индекса и длины данных. Его можно использовать для оценок, но не для перекрестной проверки. Для репликации вы можете проверить, что ведомый io и sql против ведущего запущены или нет. И relay-info вы можете увидеть соответствующие данные журнала от господина и раба.
of, конечно (1) Путь делать отсчет (*) таблиц EOD обеспечивает что данные в таблицах на оригинале и невольнике последовательны или не. Но чтобы быть точным, либо (2) Возьмите поля случайных значений и перекрестную проверку с master и slave. Кроме того, если вы не удовлетворены этим, (3) Вы можете взять их в outfile и взять diff или контрольную сумму. Я предпочитаю (1) и (2). Если (1) невозможно, (2) все еще убеждает меня. ;)