Надежная отказоустойчивая репликация MySQL - PullRequest
2 голосов
/ 06 июня 2009

Есть ли способ получить отказоустойчивую репликацию MySQL? Я нахожусь в среде, которая имеет много проблем с сетью. Похоже, что репликация получает ошибку и просто останавливается. Мне нужно, чтобы продолжать работать и восстанавливаться после этих неисправностей. Существует некоторое программное обеспечение-обертка, которое проверяет состояние репликации и перезапускает его в случае потери позиции журнала. Есть ли альтернатива?

Примечание: Репликация выполняется со встроенного компьютера с MySQL 4.1 на внешний компьютер с MySQL 5.0.45

Ответы [ 4 ]

2 голосов
/ 08 июня 2009

Ошибки репликации случаются только в том случае, если базы данных каким-то образом синхронизируются, а просто продолжение работы сервера будет означать несогласованные базы данных, я действительно сомневаюсь, что вы этого захотите.

По моему опыту, единственные случаи, когда вы сталкиваетесь с такими ошибками, это если один из главных серверов не выполнил запрос, а ведомый заметил.

В любом случае, если вы действительно хотите, чтобы подчиненное устройство продолжалось с помощью какого-то задания хрон, вы всегда можете запускать запрос каждые несколько минут, запрашивая подчиненное устройство "SHOW SLAVE STATUS", а затем проверять столбец ошибок, если он присутствует. , отправьте команду "STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER; START SLAVE;". Но, вероятно, было бы гораздо более целесообразно отправить электронное письмо администратору, когда вместо этого mysql обнаружит ошибку, поэтому он / она может выяснить источник проблемы и убедиться, что базы данных действительно синхронизированы, в противном случае вы, вероятно, увидите больше ошибок в ближайшем будущем, поскольку базы данных становятся все более и более несинхронизированными.

2 голосов
/ 08 июня 2009

Какую ошибку вы получаете? Вы также не описали, какую схему репликации или версию Mysql вы используете. Ошибки, которые вы получаете, также важны.

Репликация обычно останавливается при конфликте первичного / уникального ключа в репликации Мастер-Мастер. Помимо типовой настройки репликации Master-Slave, проблемы с сетью не должны вызывать проблем.

Попробуйте использовать Mysql 5.1 или новее, поскольку репликация в 5.0 основана на операторах и вызывает проблемы в настройках Master-Master или при использовании хранимых процедур.

(Кроме того, держитесь подальше от Mysql Cluster ... заметили совет в другом комментарии).

1 голос
/ 08 июня 2009

Репликация MySQL обычно выявляет проблемы и в любом случае восстанавливает соединение, продолжая с того места, на котором остановилась.

Если вы получаете ошибки репликации, скорее всего, источник является чем-то другим. Репликация MySQL эффективно выполняет "tail -f" в журнале запросов и воспроизводит его на ведомом устройстве (это немного умнее, но не намного).

Если базы данных не синхронизированы, репликация MySQL не обнаружит и не исправит это, но может в конечном итоге привести к его поломке, поскольку последующее обновление не может быть выполнено из-за конфликтующих данных на ведомом устройстве.

Тайм-ауты по умолчанию на ведомом устройстве репликации слишком велики - он ждет часы (или что-то в этом роде) - вы захотите уменьшить это.

Трудно избежать синхронизации данных, предпринимаются следующие шаги по смягчению:

  • Мониторинг репликации, используя что-то вроде mk-table-checkum из Maatkit
  • Аудит всего вашего кода для запросов, небезопасных для репликации
  • Если используется 5.1, переключитесь на репликацию на основе строк, которая реже страдает от этой проблемы
1 голос
/ 06 июня 2009

Рассмотрим MySQL Cluster, использующий механизм хранения NDB, он предназначен для ничего общего и отказоустойчивый

...