У меня есть сервер HAProxy, балансирующий нагрузку на два сервера mysql, которые находятся в режиме master-master / active-passive. Я вижу, что я успешно масштабировал все READS на два моих узла базы данных, но как мне легко переключить мастеров для операций записи, если текущий мастер записи выйдет из строя?
Прямо сейчас у меня есть файл конфигурации на каждом сервере приложений для DB_HOST_W для записи и DB_HOST_R для чтения. DB_HOST_R указывает на сервер HAProxy. DB_HOST_W указывает на один из главных узлов.
HAProxy автоматически выполняет аварийное переключение для операций READ, но в случае сбоя обновление файла конфигурации и изменение значения DB_HOST_W для 4+ серверов приложений потребует очень много времени.
Есть ли способ лучше? Что мне здесь не хватает?
Хочу отметить, что у меня следующая конфигурация:
server primary 10.152.142.184:3306 check
server secondary 10.152.142.185:3306 check backup
Но мне это не нравится, потому что, хотя он отправляет все операции WRITE на первичный, он также отправляет ВСЕ операции READ на первичный и устраняет масштабируемость.
Не говоря о целесообразности вашего решения, способ достижения вашей цели - определить два внешних интерфейса, прослушивающих два разных порта, например, 3306 и 3307, и два бэкэнда, один с вашей конфигурацией только для чтения и один с вашей конфигурацией записи. Затем измените свое приложение, чтобы DB_HOST_R и DB_HOST_W могли включать номер порта.
Другое решение - назначить серверу другой IP-адрес и привязать два внешних интерфейса к конкретным IP-адресам, а не bind *:3306 и два бэкенда, как указано выше.
В идеале ... это должно быть реализовано на стороне приложения.
Для реализации на стороне сервера мы использовали Кластер MySQL . Я всегда считал, что установка MySQL типа master-master требует больше работы, чем она того стоит.
Основная проблема, с которой вы столкнетесь при этой настройке, - keepalive поведение. Если ваше приложение ожидает взаимодействия с той же базой данных, и оно терпит неудачу (или просто балансирует нагрузку на другую), вы жестяная банка увидеть интересные ошибки в зависимости от вашей реализации.
Короткие && Длинные
MySQL Cluster предназначен для такого рода вещей, но есть ошибки которые вам нужно будет обсудить со своими командами разработчиков / систем.