Комментарии 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 кластеров такая взаимная неприязнь .... ну я не знаю как это прокоментировать. нормальных слов у меня нет.
Можете привести расчет надежности своего "отказоустойчивого кластера"? Или подобного. Включая состояние "отказ, необнаруженный внутренней системой управления кластера".
Не проще на pacemaker кластер собрать?
Дверь в лето - лучшая фантастика про кота )))
Остальное прочитал по диагонали и не понял )))
Вместо vip и haproxy можно использовать встроенный в libpq функционал.
Указать несколько серверов в строке подключения, задать target_session_args, там же и балансировка простая есть (для чтения).
Вот тут кратко.
Вы сами-то проверяли отказоустойчивость?
Запустите какую-нибудь обработку, которая будет писать или обновлять данные.
Выключите мастер-сервер, включите его.
После старта бд старого мастера, теперь выключите новый мастер.
А теперь ищите нового мастера... и посмотрите что и где пропало.
А теперь повторите эксперимент с базой размером больше 500гб
Я вот пробовал все это, результат не понравился. Часть данных пропала (я знаю про синхронную репликацию, а автор статьи?) Старый мастер начал пытаться стать репликой нового мастера и не смог. Да, у меня руки кривые, но где тогда надежность.
Безусловно проверял. Я бы не стал обманывать столь уважаемую аудиторию хабражителей.
Чуть позже подъедет видео, там будет видно как проходит свитчовер и база не рушится.
И в планах записать полноценное нагрузочное тестирование.
Дело не в размере базы, а в том насколько плотно в ней работают пользователи и успевает ли реплика за лидером
Пропадет то что было в транзакции, аналогично как бы оно пропало при разрыве сети.
По поводу больших баз уже писал, это не повод для хвастовства, а повод присмотреться все ли корректно.
Есть простое как гвоздь эмпирическое правило: Если база не сворачивается, она наворачивается.
а стоят ли эти пресловутые 10% скорости БД которые всё равно не заметно из-за кривой конфигурация сервера приложений 1с - той надежности и простоты масштабирования которую дает Haproxy?
и вобще а почему у вас Haproxy считается точкой отказа?
Насчет точки отказа очевидно если он один и устает, то вся конструкция рушится.
Расскажите и вы про кривой конфигурация сервера приложений 1с и про то что за надежности и простоты масштабирования которую дает Haproxy
Построение отказоустойчивого кластера PostgreSQL для 1С. HAProxy, давай до свидания. Рецепты от Капитана