Мне бы хотелось получить отзывы об этой стратегии восстановления после отказа для пары серверов MySQL, которые я разрабатываю для кластера, и я хочу проверить, есть ли что-то очевидное, чего я здесь не упускаю.
Один сервер приложений, который подключается к главному серверу mysql в повседневных операциях, и у которого есть сервер mysql, настроенный в качестве подчиненного устройства для целей репликации главный-подчиненный.
Если сервер mysql выходит из строя, я хочу, чтобы веб-приложение попыталось подключиться к мастеру, а затем после n неудачные попытки выполните следующее:
После того, как приложение снова будет запущено и будет обслуживать пользователей, я хотел бы иметь возможность запускать новый подчиненный сервер в фоновом режиме, когда он будет готов обслуживать запросы, снова настроить репликацию главного подчиненного устройства, чтобы обеспечить ту же поддержку аварийного переключения, что и перед.
Я почти уверен, что это было сделано раньше, но я не вижу никаких руководств по этому поводу, поэтому я предполагаю, что должна быть какая-то очевидная причина, по которой вы не попробуете это, о которой я еще не подумал.
В чем заключаются подводные камни такого подхода для обеспечения автоматического переключения при отказе, подобного этому, с MySQL?
Кстати, я знаю о репликации мастер-мастер, но а) я видел, как все шло не так, и это б) кажется тревожно чрезмерно сложным.
Спасибо
Вам нужен кластер высокой доступности, и я думаю, что предложенный вами подход кажется немного странным.
Хороший способ добиться этого - создать Linux HA-кластер и синхронизировать MySQL с помощью синхронизации DRDB на уровне файловой системы.
В такой конфигурации у вас есть 3 вещи:
Вместо того, чтобы писать много кода в вашем приложении, вы используете виртуальный 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/
Причина, по которой автоматическое переключение при сбое не способствует, связана с задержкой репликации. Если ведомое устройство отстает и происходит переключение при отказе, возможно, вы записываете обновления с ключами, которые еще не существуют, потому что вставки от ведущего еще не были записаны. Чем больше задержка репликации, тем больше проблема. В моей компании мы используем DRBD для автоматического переключения при отказе, поскольку сервер DRBD, на который выполняется переключение, является точной копией исходного мастера на уровне диска. В качестве политики мы выполняем ручное переключение при отказе для установок главный / подчиненный и главный / главный.
Я бы не исключил репликацию мастер-мастер. Фактически то, что вы описываете, является почти репликацией мастер-мастер.
Взгляните на MMM (Multi-Master Replication Manager для MySQL). http://mysql-mmm.org/ Он работает на уровне mysql, поэтому работает намного лучше, чем кластеризация на основе ОС.