@pashaxp

Как лучше организовать отказоустойчивость между дата-центрами?

Добрый день.

Имеется некий проект, для которого самым ценным и наиболее часто меняющимся является БД - mysql.
Код, к примеру, редко меняется, и его легко восстановить.

Задача такова: нужно организовать катастрофоустойчивость таким образом, чтобы при любых обстоятельствах сохранить БД в рабочем состоянии и по транзакциям - по возможности самой последней версии, ну или N-m (где N - основное, достаточно большое количество уже имеющихся записей в БД, и m -потеря нескольких последних транзакций, когда виртуалка с основной системой упала, и несколько последних запросов могли не обработаться)

Есть мысль сделать БД на каком-то очень устойчивом к отказам хостинге вроде Amazon, где mysql будет всегда (ну или почти всегда ) работать. А из виртуалки с кодом, из любых дата-центров, где бы я его не разместил, будет прописан коннект к Амазон-хранилищу.

И быстрыми NS-ами буду переключать точку входа в проект, менять А-запись для домена, в последствии автоматизирую это переключение.

Как мне видится, способ не особо затратный и вполне рабочий.
Но может есть и получше?
  • Вопрос задан
  • 791 просмотр
Решения вопроса 1
@pashaxp Автор вопроса
В любых ОС реализовано кэширование DNS. Если возможности его отключить нет, то идея с DNS скорее всего провальна. Да и смотря сколько кэш держит.


Здесь упор на пользователей. Если основной сервер упал, надо менять А-запись, иначе проект будет недоступен. Кэшированием пренебрегаем. И оно, насколько мне известно, происходит на промежуток времени, не более , чем TTL у домена. А если TTL достаточно маленький в настройках NS-серверов, переключение будет быстрым. Так ведь работают все сколько-нибудь большие публичные сервисы. Постоянно меняют А-записи.

Хотел бы ещё прояснить, как поведёт себя проект, если А-записей будет несколько? И точек входа, фронт-енд, тоже. Тут действительно , не обойтись без mysql master-master...
Ответ написан
Пригласить эксперта
Ответы на вопрос 4
opium
@opium
Просто люблю качественно работать
Для распределенной системы только репликация никакой кластер не будет нормально работать в разнесенных дц.
Сделайте мастер слейв реплику и переключайтесь на второй сервер в случае проблем.
Ответ написан
Комментировать
He11ion
@He11ion
PHP-monkey
Кластер с репликацией - нет? Ну и вместо MySQL я б советовал смотреть в сторону Посгреса.
Ответ написан
@dredd_krd
И быстрыми NS-ами буду переключать точку входа в проект, менять А-запись для домена, в последствии автоматизирую это переключение.

В любых ОС реализовано кэширование DNS. Если возможности его отключить нет, то идея с DNS скорее всего провальна. Да и смотря сколько кэш держит.

Как мне кажется, можно сделать репликацию master-master между двумя хранилищами, и в коде фронтенда (если же он будет находиться в третьем месте) при сбоях (возможно даже автоматом) переключать БД с одного хранилища на другое. При восстановлении связи отставшая база наверстает упущенное, и можно будет переключать обратно, если она является самой оптимальной по производительности.
Ответ написан
Комментировать
ifaustrue
@ifaustrue
Пишу интересное в теллеграмм канале @cooladmin
По отказоустойчивости точки входа трафика - можно например арендовать на том же Амазоне виртуалку, и на ней поднять nginx с проксирвоанием трафика на ваши виртуалки, за аренду такой тачки будут сущие копейки, а доступность у ней будет в разы больше. Не придётся городить огород с DNS и всегда можно будет поднять заглушку на случай падения обоих бакендов.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы