Как бюджетно реализовать распределенный сервер БД?
Ситуация:
Есть ПО, работающее на postgreeSQL, ПО предназначено для фитнес-клубов.
Есть 3 клуба, в каждом из которых стоит отдельный физический сервер, к нему подключен СКУД, который управляет турникетами, СКУД работает в связке с этим ПО.
Стоит задача: организовать единый доступ к БД, по возможности отказоустойчивый.
Что я понимаю (как мне кажется): смотрел в сторону шардинга, но понял, что это должно быть реализовано на уровне схемы БД.
Думал насчет репликации, с раположением в каждом клубе SLAVE-сервера, но мне непонятен процесс "экстренной" работы, когда slave оказывается без доступа к мастеру. Запись то в него осуществлять нельзя...или можно? как потом обеспечить консистентность данных?
Мой выход (как мне кажется) - реализовать распределенную систему хранения данных, на которую я уже установлю БД, НО не будет ли это слишком медленным решением?
Сама база - около 200 Мб, количество одновременных пользователей в пике - 20 человек + 3 СКУД
Собственно вопрос: что можете посоветовать в условиях ограниченности бюджета и не слишком высокой технической грамотности человека, на чьи плечи свалилась такая радость?
Евгений, 3 клуба, распределены географически.
Клубы строились в разное время и на тот момент проще было поставить "калькулятор" назвать его сервером и подключить к нему всё, обеспечив работу СКУД вне зависимости есть или нет интернет.
Сейчас стоит задача базы слить в одну, но при этом хотелось бы вот это вот спокойствие, что турникет у тебя работает вне зависимости от интернета, сохранить
Роман Мирр, да, это три абсолютно одинаковых экземпляра ПО, одна и та же схема СУБД, которую разработчики менять не будут точно.
Я им задал вопрос про шардинг примерно месяца 4 назад, но они посмотрели на меня как то странно и никаких подвижек нет.
Вообще, как ни странно, проблему предлагают решать тупо резервированием каналов, но я чувствую, что должно быть некое решение ещё и на уровне БД либо СХД.
Однако, я не являюсь специалистом в этих областях, поэтому вынес вопрос на общее обсуждение
Вероятные поломки делают Master-Master репликацию непривлекательной. Выход из строя одного из серверов практически всегда приводит к потере каких-то данных. Последующее восстановление также сильно затрудняется необходимостью ручного анализа данных, которые успели либо не успели скопироваться.
Используйте Master-Master репликацию только в крайнем случае.
