Есть небольшой проект работающий на php, с базой mysql, rabbitmq, на этих сервисах завязаны бизнес процессы "оффлайн" маленькой компании. Сейчас размещаем все в РФ на маленьком дешевом VDS, все устраивает, пинг хороший, скорость отличная, НО периодически раз в 2-5 мес. у провайдера падает сеть минут на 15, причем в самый неподходящий момент. Есть дешевый вариант VDS за границей, буквально за теже деньги можно взять 3 VDS. В момент того как сервер недоступен, хочу перебивать A записи в DNS и переключаться на резервный сервер, как синх. файлы более менее понятно, есть куча способов. А вот что делать с MYSQL базой?
Сделать репликацию MASTER-MASTER? Если сервер 1 не доступен, а на резервном сервере изменения в БД, какие последствия ждут? Какие решения существуют для этого? Какие подводные камни есть при реализации такой репликации? Боюсь что есть большой шанс похерить базу MYSQL.
1) master-master на mariadb - каждый сервер будет иметь свой уникальный gtid и именно мария в отличии от оригинального mysql умеет хорошо разруливать бинарные логи и даже мульти репликацию. Но нужно как минимум прописать сдвиг auto_increment на северах, чтобы он были уникальными
2) galera cluster - где-то на 30% медленнее - транзакция должна пройти на всех нодах, только innodb движок, нужно следить, чтобы не было myisam, нужен кворум нод, то есть две ноды лучше не делать, если одна 100% будет уходить в оффлайн
В первом случае синхронизация может быть с небольшой задержкой на сложных изменениях, но сама схема вполне рабочая.
Все рецепты настроек есть в гугле :)
НО периодически раз в 2-5 мес. у провайдера падает сеть минут на 15
Это не та проблема, когда надо городить огород, в котором плохо разбираетесь. Еще хуже сделаете.
Наверняка есть провайдеры без таких провалов. Но мне не встречались. При том, что не всё от них зависит.
Если компания оффлайн то почему бы для надежности просто не поднять и настроить свой сервер в офисе этой компании и ничего не бояться?
Что бы советовать как лучше дублировать данные бд на другом сервере слишком мало информации о характере бд и проводимых в ней транзакциях. При определенных условиях ничего не мешает реализовать репликацию на том же php....
Haproxy + galera + Xtradb от percona, для деплоя посмотрите на готовые ansible плейбуки.
Не забываем про critical read в mysql части и "липкие коннекты" в haproxy.
Кластер минимум 3 годы, чтобы не было split brain, если по феншуям хочется, то 5 лучше нод.
за наводку на galera + Xtradb от percona спасибо, а вот Haproxy не наш вариант, мне балансировка нагрузки не нужна, да и тем более в разных ДЦ сервера.
stratosmi, идея в том что бы иметь 3 ноды, 1 продакшен, 2 в запасе (крутятся внутренние демоны, работают с БД), если мониторинг находит что нода 1 не работает, перебивает скриптом через API DNS-хостинга A запись на вторую ноду :) Конечно TTL придется ставить маленький.
В случае с бд это катастрофически долго. Haproxy переключит намного быстрее и самый кайф в том, что нет этих костылей из скриптов со всякими api и dns. А ещё, если приложение это демон, то не нужно будет думать о кешиповании днс и перезапусках/релоадах демона.
exhang, как показывает практика этот сервер не прихотлив и не склонен к падениям. И его можно ставить прямо на сервер с приложением. Приложение подключается на локалхост, где живёт хапрокси, а он уже выбирает к какому серверу бд подключаться. Типа как nginx и апач, если такое сравнение уместно.
Простой
