И снова здравствуйте. Есть рабочий сервер на котором содержится всего лишь один проект. Проект черезвычайно важен и стабильность его работы это деньги компании. Пришло время придумать запасной вариант на случай если что то пойдет не так (ляжет сервер, дата-центр скажет аривидерчи или еще что то). Словом, нужен зеркальный сервер который будет дублировать первый и в случае отключения первого либо сбоя, все запросы будут уходить на зеркало. Кто подскажет, в какую сторону смотреть для реализации сего задума?
Нанять системного администратора, он настроит на разные дата центры, думаю предложит облачные, чтобы платить минимум пока работает рабочий сервер
берется в хецнере вторая железка с которой синхронизируется боевой сервер. Берется виртуалка в том же хецнере на котором разворачивается балансир и настраивается так что роутит запросы на слейв если лежит боевой сервер. Всё. И да, настроить все может разово сисадмин любой или спецы провайдера. Если полагается что датацентр хецнера ляжет вероятнее чем ваши приложения, то точно также масштабируете на другой датацентр.
Ну схему с двумя железками реализовать это понятно. Вместо роутера в виде отдельного сервера можно использовать настройки доменного имени. Суть вопроса на данном этапе в том, как делать синхронизацию на лету. Менять весь код системы и добавлять двойные функции или есть более простой вариант
базы живут на отдельных серверах образуя кластеры в таких проектах. Синхронизироваться умеют из коробки большинство зрелых и популярных СУБД, либо доставляется и настраивается отдельный их компонент для этого (кластеры) либо обходятся репликацией. Исчерпывающих инструкций и для того и другого полно.
ох не всё оно так просто. например, когда ведущий сдох, то ты переключаешься на ведомого, но он-то настроен как ведомый, а не ведущий, и когда ведущий поднимется, то его поднимать как ведущего или как ведомого? И что потом делать?
Тут практики нет, но обычны в дата центре должен быть отдельный тупой сервер или роутер который мало вероятно если упадёт, и то если падает, сразу может подняться. Вот он и должен переключать веб трафик, для баз думаю такой вариант тоже можно настроить. Думаю большие проблемы возникают когда не хватает ресурсов.
К примеру, в случае текущего проекта, если говорить о базах данных (и не только), то есть балансиры к которым подключаются клиенты, обращаясь к серверу баз данных, а те уже разруливают куда роутятся запросы - на мастера или на слейв. Балансир в данном случае это обычная виртуалка на CentOS. А разруливать трафик в простом случае можно, банально, доменными записями, что и делается. Первый не ответил - будет валиться на второй, они в конкретном примере равноценны.
я не о том спросил. Я говорю, когда мастер вернулся в мир живых, он будет ли мастером? (брадобрей который бреет себя является ли брадобреем)
так у него данные устаревшие, нафик он нужен такой мастер? Слейв работал на запись несколько часов, теперь только у него данные свежие.
Сервера бд обычно в кластере, между ними настроена синхронизация (i.e. https://docs.mongodb.com/manual/core/sharded-cluster-components/ как у нас)
дык она настроена. Поэтому когда мастер упал - запросы на запись и любые другие изменения посыпались на слейва. Через какое-то время ты мастера поднимаешь. На нём устаревшая инфа, понимаешь? Ты должен мастера со слейвом местами поменять. Но слейв-то настроен как слейв. Если вдруг они решат синхронизироваться, что будет? Уверен ли ты, что всё пройдёт как надо? =) Врубаешься? --- Добавлено --- монго тут вообще не при делах, это не классическая бд, там изначально нет гарантии консистентности прямо в доке написано и на этом там этот вопрос закрыт. А в мускуле с посгресом че делать? =)