Comments 19
неужели "active-active" кластер? или просто очередной костыль для некластеризуемого PostgreSQL community edition ?
"active-active" кластер 1С не умеет
но это не костыль
PostgreSQL community edition это что за зверь?
"PostgreSQL community edition это что за зверь? " <-- дык ... это обычный postgres. просто есть компании которые делают свои расширения и они платные. Соответственно, вместо всего этого зоопарка вы могли просто поставить какой-нибуть платный PostgreSQL PRO ... и получить active-active кластер из коробки. ну ... типа того
Вообще .... все попытки построить что-то на базе PostgreSQL community edition ... это как тюнить запорожец в надежде получить болид Формулы 1. Нужно смотреть в сторону кластеризуемых решений на базе NewSQL. cockroachdb, yugabytedb и т.д.
Извините если обидел.
PostgreSQL PRO мультимастер тоже не поддерживает 1С или наоборот
Вообще нет данных про active-active кластер PostgreSQL для 1С
NewSQL. cockroachdb, yugabytedb и т.д. тоже 1С не поддерживает
Никаких обид
А в чем зоопарк то? Postgres Patroni etcd вроде ничего навороченного
"А в чем зоопарк то?" ну .... просто много разных компонент :-) схема масштабная.
Если у 1с и active-active кластеров такая взаимная неприязнь .... ну я не знаю как это прокоментировать. нормальных слов у меня нет.
Скорее всего допилят либо те либо другие, просто раньше это было не актуально.
Да и в принципе это для 1С не так актуально, т.к. основная нагрузка идет на сервер приложений 1С, он поддерживает active-active и балансировку, а СУБД гораздо меньше нагружена, там важнее просто отказоустойчивость
Можете привести расчет надежности своего "отказоустойчивого кластера"? Или подобного. Включая состояние "отказ, необнаруженный внутренней системой управления кластера".
Не проще на pacemaker кластер собрать?
Дверь в лето - лучшая фантастика про кота )))
Остальное прочитал по диагонали и не понял )))
Вместо vip и haproxy можно использовать встроенный в libpq функционал.
Указать несколько серверов в строке подключения, задать target_session_args, там же и балансировка простая есть (для чтения).
Вот тут кратко.
Вы сами-то проверяли отказоустойчивость?
Запустите какую-нибудь обработку, которая будет писать или обновлять данные.
Выключите мастер-сервер, включите его.
После старта бд старого мастера, теперь выключите новый мастер.
А теперь ищите нового мастера... и посмотрите что и где пропало.
А теперь повторите эксперимент с базой размером больше 500гб
Я вот пробовал все это, результат не понравился. Часть данных пропала (я знаю про синхронную репликацию, а автор статьи?) Старый мастер начал пытаться стать репликой нового мастера и не смог. Да, у меня руки кривые, но где тогда надежность.
Безусловно проверял. Я бы не стал обманывать столь уважаемую аудиторию хабражителей.
Чуть позже подъедет видео, там будет видно как проходит свитчовер и база не рушится.
И в планах записать полноценное нагрузочное тестирование.
Дело не в размере базы, а в том насколько плотно в ней работают пользователи и успевает ли реплика за лидером
Пропадет то что было в транзакции, аналогично как бы оно пропало при разрыве сети.
По поводу больших баз уже писал, это не повод для хвастовства, а повод присмотреться все ли корректно.
Есть простое как гвоздь эмпирическое правило: Если база не сворачивается, она наворачивается.
а стоят ли эти пресловутые 10% скорости БД которые всё равно не заметно из-за кривой конфигурация сервера приложений 1с - той надежности и простоты масштабирования которую дает Haproxy?
и вобще а почему у вас Haproxy считается точкой отказа?
Насчет точки отказа очевидно если он один и устает, то вся конструкция рушится.
Расскажите и вы про кривой конфигурация сервера приложений 1с и про то что за надежности и простоты масштабирования которую дает Haproxy
Построение отказоустойчивого кластера PostgreSQL для 1С. HAProxy, давай до свидания. Рецепты от Капитана