Надежная отказоустойчивая репликация MySQL

Question

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

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

Answer 1

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

• репликация Monitor используя что-то вроде Mk-таблицы-контрольной суммы от Maatkit
• аудита всего кода для репликации небезопасных запросов
• Если вы используете 5.1, переключитесь на репликацию на основе строк, которая с меньшей вероятностью пострадает от этой проблемы

Answer 4

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

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

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