Как выполнить восстановление после сбоя в настройке асинхронной репликации MySQL / InnoDB Master-Slave?
В частности:
Если подчиненное устройство выходит из строя, как мне заставить его синхронизироваться с мастером после того, как я верну его к работе?
Если мастер выходит из строя, подчиненный становится мастером. Как мне сделать так, чтобы новый мастер синхронизировался с другими подчиненными? И когда будет восстановлен исходный мастер, как мне синхронизировать его с новым мастером?
Поскольку репликация является асинхронной, транзакция, которая была зафиксирована на главном сервере, может быть не в состоянии покинуть мастер до того, как произойдет сбой. Таким образом, может быть несоответствие между исходным мастером и подчиненными, один из которых станет новым мастером.
Точно так же ведомое устройство, которому назначено новое ведущее устройство, может не иметь самых последних транзакций среди всех ведомых устройств. Таким образом, новый хозяин мог быть «позади» одного из своих рабов.
Как мне разрешить все эти потенциальные несоответствия?
Какие инструменты помогут с этими задачами?
Спасибо.
Я бы рекомендовал избегать МММ как чумы. Это очень рискованное программное обеспечение, которое вызывает гораздо больше простоев, чем предотвращает. У меня большой опыт работы с этим, и моя компания пыталась исправить его проблемы, но это не исправимо. Я не уверен, уместно ли размещать ссылку на мой пост в блоге, где я объясняю, почему это правда. Первоначальный автор «МММ», кстати, соглашается, что это катастрофа.
Главный инструмент, который я рекомендую, это ммм. Он обрабатывает циклическую репликацию, несколько ведомых устройств, переключение на резерв и автоматическое продвижение к ведущему (и соответствующее повторное указание ведомых устройств), все прозрачно для клиентов через управляемые плавающие IP-адреса, и он прекрасно работает (у меня был основной сервер БД, исчезнувший вчера вечером из-за мертвого переключение, а мои клиенты даже не заметили).
В сочетании с mmm я бы рекомендовал xtrabackup так как его можно использовать как действительно быстрый и элегантный способ установки новых ведомых устройств (возможно, для замены умершей машины), намного быстрее, чем загрузка из дампа sql.
Также, если вы архивируете свои резервные копии, вам НЕОБХОДИМО свинья - это сократит время резервного копирования на ~ 80%!
Я попробую:
Slave_IO_Running: Yes Slave_SQL_Running: Yes Last_Errno: 0 Last_Error: Seconds_Behind_Master: 0
Если так выглядит, все в порядке. Если Seconds_Behind_Master> 0, реплика догоняет. Если Slave_IO_Running не запущен, у вас нетипичная проблема, проверьте журналы ошибок. Если Slave_SQL_Running не запущен, попробуйте запустить его с помощью «START SLAVE;». Если это не удается, проверьте, есть ли ошибка, указанная в строке «Last_Error».
Чтобы повторно синхронизировать старый мастер, просто добавьте его в качестве подчиненного и дайте завершению репликации. Затем вы можете отключить систему и вернуться к старому мастеру.
Сделки - это проблема. Особенно, если вы используете бэкэнд, не зависящий от транзакций, например MyISAM. Использование InnoDB должно работать. AFAIK только завершенная транзакция записывается в binlog и, следовательно, в реплики. Это будет применяться только в том случае, если база данных знает о ваших транзакциях.
С помощью команд, приведенных ранее, вы можете проверить состояние всех ваших ведомых устройств и перевести самое свежее (подсказка: Log_Pos) ведомое устройство в ведущее. может быть, просто временно, пока все подчиненные устройства снова не будут обновлены, а затем продвинуть назначенный сервер.
Лично я думаю, что вам понадобится специальная настройка (например, смешивание ведомых устройств WAN и LAN, огромные запросы транзакций), чтобы иметь ведомые устройства с разными состояниями реле после сбоя ведущего.