репликация

В процессе длительной работы с двумя и более MySQL баз данных, между которым происходит репликация, можно столкнуться с массой мелких ошибок, вызванных, например, конфликтами первичных ключей, повреждениями журналов и т.п. Особенно, если репликация настроена, как мастер-мастер, конфликты гарантированы. Естественно, из-за мелких ошибок никто не станет полностью заново синхронизировать две базы данных, а скорее всего, пропустит ошибку через установку SQL_SLAVE_SKIP_COUNTER или slave-skip-errors. Со временем, две БД накопят некий запас неконсистентности, благодаря таким пропущенным конфликтам. Итак, что делать, если нужно восстановить полную консистентность, или в случае, когда ошибка в репликации совсем критичная и не решается вышеописанными способами? Единственный выход - полная синхронизация двух БД "с нуля" и сброс состояния репликации.

Порядок действий таков - на мастере:

Сохраните вывод последней команды. Первая команда нужна только в случае мастер-мастер репликации. Вторая и третья команды сотрут все журналы мастера, предназначенные для слейвов и переведут все таблицы в режим только чтения, чтобы во время переноса дампа не появилось никаких новых данных.

На днях на одном из серверов внезапно остановилась репликация. Команда SHOW SLAVE STATUS показала ошибку: Last_Error: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave. Выглядит внушительно и слегка пугающе - все таки, не каждый день повреждаются файлы на жестком диске, к тому же файлы журнала репликации. Так или иначе, с ошибкой надо что-то делать и как всегда есть два варианта: простой, надежный, но муторный, связанный с ручной синхронизацией БД через импорт/экспорт, либо быстрый, но требующий внимания, т.к. связан со сбросом текущего положения "курсора" репликации на проблемном сервере.

Какое бы решение вы не приняли, оно поможет от любых ошибок репликации, связанных с повреждением журнала на подчиненном (слейв) сервере. Если бинарный журнал повредился на главном (мастер) сервере, статью дальше можно не читать. Итак, я пошел вторым путем, т.е. через сброс состояния репликации. Все, что нужно сделать - это выполнить несколько команд на проблемном сервере. Поехали:

Если у вас есть сервер, на котором настроена MySQL репликация, то рано или поздно вы столкнетесь с разного рода ошибками этой самой репликации. Ошибки могут быть вызваны как некорректной настройкой mysql-сервера, так и неправильной структурой самой БД.

В моей практике, наиболее распространенной ошибкой была 1062 Duplicate entry '...' for key 1, которая возникает в случае нарушения уникальности какого-либо unique-поля таблицы. Если вы не можете изменить структуру таблиц так, чтобы избежать подобной ситуации, но, при этом, репликацию надо как-то запускать, есть простой выход - в настройки MySQL (my.cnf) добавить строку slave-skip-errors = 1062. С этого момента, сервер просто будет игнорировать именно эту ошибку и репликация останавливаться не будет. Но надо понимать, что при таком подходе вы будете терять часть данных, которые не попадут в реплицируемые таблицы из-за описанного выше конфликта.

Многие используют в MySQL функцию Master - Slave репликации для зеркалирования или бекапа данных. А что, если slave должен иметь возможность записать данные в БД, которые затем должны реплицироваться на Master? Настройка Master - Master репликации на самом деле не представляет из себя ничего сложного.

Дано:

• Хост 1 (192.168.1.1) - главный сервер
• Хост 2 (192.168.1.2) - второй сервер, зеркало первого, который должен реплицировать все с главного, а также передавать ему свои изменения

Необходимо настроить мастер-мастер репликацию между главным сервером и зеркалом. Поехали!

На главном сервере:

• В файле конфигурации MySQL (my.cnf) отключаем параметр skip-networking и прописываем в bind-address внешний IP данного сервера