Автоматизированная стратегия отработки отказа для репликации "главный-подчиненный" Mysql - почему бы это не сработало?

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

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

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

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

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

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

Каковы недостатки использования этого подхода для обеспечения автоматического переключения при сбое, как это с MySQL?

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

Спасибо

Источник

3 ответа

Решение

Причина, по которой автоматическое переключение при отказе не способствует, связана с задержкой репликации. Если ведомое устройство отстает и происходит аварийное переключение, возможно, вы пишете обновления с ключами, которые еще не существуют, потому что вставки из мастера еще не были записаны. Чем больше задержка репликации, тем больше это проблема. В моей компании мы используем DRBD для автоматического перехода на другой ресурс, так как сервер DRBD, на который вы переключаетесь, является точной копией исходного диска на уровне диска. в качестве политики мы делаем руководство по переключению при сбое для основных / подчиненных и основных / основных настроек.

Источник

Вам нужен кластер высокой доступности, и я думаю, что предложенный вами подход кажется немного странным.

Хороший способ добиться этого - создать кластер высокой доступности Linux и синхронизировать MySQL с помощью синхронизации DRDB на уровне файловой системы.

В такой настройке у вас есть 3 вещи:

  1. Уровень обмена сообщениями кластера (Linux-HA или CoroSync)
  2. Диспетчер ресурсов кластера (кардиостимулятор)
  3. Синхронизация диска (DRDB)

Вместо того, чтобы делать много кода в вашем приложении, вы используете виртуальный IP-адрес, который вы перемещаете к текущему активному узлу. Также вы используете STONITH (Shoot The Other Node In The Head (я не придумал это)), чтобы убедиться, что первый узел действительно мертв, прежде чем пытаться захватить ресурсы.

Есть несколько отличных материалов для чтения по этим ссылкам: http://www.linux-ha.org/wiki/Main_Page http://www.clusterlabs.org/wiki/DRBD_MySQL_HowTo http://theclusterguy.clusterlabs.org/

Источник

Я не исключаю репликации мастер-мастер. На самом деле, то, что вы описываете, является почти репликой мастер-мастер.

Посмотрите на MMM (Multi-Master Replication Manager для MySQL). http://mysql-mmm.org/ Работает на уровне mysql, поэтому работает намного лучше, чем кластеризация на основе ОС.

Источник
Другие вопросы по тегам