Как стать автором
Обновить

Комментарии 23

Добрый день.
Минусы Редис вы привели.
Можно узнать, по каким причинам были отвергнуты Mongo, Raven, или результаты анализа являются NDA?
Спасибо.

Лично у нас мешают таким подвижкам отсутствие знаний, времени на тестирование и достаточной экспертизы, опять же опыт коллег из других контор, что на самом деле помогло внедрить кликхаус. Потом доля рынка, далеко не последний показатель.

Пытался внедрить patroni год назад и выкинул. Вот почему:
1. Неофициальные образы в docker hub. Они самописные, куда не так просто добавить свои расширения и прогнаны через docker-squash, что усложняет диагностику.
2. Они используют свои абстракции над конфигами, поэтому не все директивы конфига постгреса можно переопределить.
3. Сабж завязан на возможности hot standby. При использовании hot standby пропадает возможность использования максимального уровня изоляции транзакций (serializable), что было неприемлемо для нашего проекта.
Я конечно продукт господина Александра Кукушкина — разработчика Patroni из Zolando не продвигаю и не защищаю, но:
1. Никто не мешает собирать свой образ и хранить в своём репозитории, как и образы с апликухой, которые в рамках релиза выезжают в продакшн
2. Там всего несколько директив постгрешных: max_connections, max_locks_per_transaction, max_worker_processes, max_prepared_transactions, wal_level, wal_log_hints, track_commit_timestamp, max_wal_senders, max_replication_slots, wal_keep_segments
3. Вот здесь я не очень понял параллель уровня изоляции транзакций и hot standby — возможность чтения с реплики
1. Правда. Но это уменьшает его ценность, как «изкоробочного» решения
2. И как только потребуется переопределить что-то не входящее в этот список, начинаются сложности
3. Ограничение PostgreSQL, больше инфо здесь, параграф «Caveats»: www.postgresql.org/docs/10/hot-standby.html

И что в итоге внедрили?

1. Как уже подсказали, ничто не мешает использовать свой docker образ или можно обойтись без docker.
2. Здесь хочется примеров того, что нельзя переопределить. В нашем случае мы еще не сталкивались с такой ситуацией. И если она существует, то будет полезно знать об этом заранее.
Локальные консул агенты обязательно нужны на всех хостах.
Просто роли у них должны быть просто agent, а не master.
Вообще если мне память не изменяет, это best practice для консула.
Локальны консул агенты, это одна из точек отказа, но никто не мешает использовать etcd, где нету никаких агентов
Спасибо за комментарий,
да, это best practise, но опять же не для всего и в случае с patroni нет правильного решения. Мы попробуем и использование consul agent и попробуем поправить проблему в коде patroni. И хотим делать эти два решения параллельно и независимо друг от друга, а потом посмотрим что из этого получится.
Многолетний опыт экспулатации патрони с консулом (и далеко не только патрони) показывает, что локальные агенты решают кучу проблем — распределение нагрузки (особенно днс чтения для клиентского сервис дискавери), да возможность нормально использовать сервис дискавери как таковой.

У нас на консуле построено вообще все, и без локальных агентов, как изначально мы тоже пробовали, было все сильно хуже.

И впиливание костыля в патрони, ради избегания best-practice другого инструмента…
Ну хз. Врядли в апстрим возьмут. ;)

Интересная история, «но есть нюанс».
Исключительно из любопытства — вы пробовали посчитать, во сколько обошлось и обойдётся подобное кастомное решение в сравнии с RDS?
Не с точки зрения стоимости инстанса, а за все, включая работу.

Зато у людей нормальное переносимое решение, а если амазон вдруг решит, что у них теперь очень хороший посгрес и надо поднять ценник за него раза в 2 (гугл ведь так не раз делал, МС делал, чем мы хуже?), то с RDS так просто не спрыгнуть.
Другое дело — вообще не понимаю зачем они в амазоне железо покупают, если и так куча резервов… чем хетцнер с их бросовыми железяками не подходит?
Если посмотреть на status page hetzner, то вопросов не должно быть. У них не так все хорошо с доступностью.

Я бы взял 50-80% мощности у хетцнера, остальное у другого хостера, так можно нехилые суммы сэкономить. Распределение между хостерами это бестпрактис.

Пробовали и в итоге получилось, что уже большая часть была готова поэтому стоимость уже выполненых работ не стоит учитывать.
Еще один минус, на RDS нельзя делать тонкие настройки, а для нас это иногда необходимо
При этом мы не могли хранить весь объём данных в PostgreSQL и для нас была важна скорость работы с базой, поэтому мы начали шардировать PostgreSQL на прикладном уровне.

В итоге шардируете на прикладном уровне или нет?
На Etcd не хотите переходить?
Шардируем на прикладном уровне.
На etcd переходить пока не планируем, есть кластер consul и он должен использоваться не только для patroni, что сейчас и происходит.
На etcd переходить пока не планируем

Для информации:
Используем аналогичное HA решение PostgreSQL на выделенных физических серверах (на базе Patroni + etcd), в production (более года), проблем с etcd у нас не было.
Главное, на этапе планирования, учесть требование к дисковому и сетевому latency, оно не должно быть большим. Мы храним данные etcd на отдельных (от данных БД) дисках (на каждой ноде кластера Patroni).

Кластер etcd очень чувствителен к задержкам на диске.
Активность на диске из других процессов может привести к длительным задержкам fsync. В результате, etcd может пропустить биение сердца (heartbeats), вызывая тайм-ауты запроса (request timeouts) и временную потерю лидера etcd.
Избегайте хранение данных etcd на дисках совместно с другими процессами, интенсивно использующими ресурсы дисковой подсистемы! По возможности, хранить данные etcd на ssd дисках.

Кластер etcd, как правило, строим из 3-х, либо 5-и серверов, не более.

Схема выглядит следующим образом:
github.com/vitabaks/postgresql_cluster/blob/master/TypeA.png

Для систем без необходимости распределения (читающей) нагрузки, используем упрощённую схему, в которой (в добавок к patroni и etcd) используется только «vip-manager» (Manages a virtual IP based on state kept in etcd or Consul. Monitors state in etcd).
github.com/vitabaks/postgresql_cluster/blob/master/TypeB.png
При этом, pgbouncer статичен (нет необходимости менять его конфиг), он привязан к конкретному локальному экземпляру PostgreSQL, и в принципе — опционален. Рассматриваем возможное использование пуллера Yandex odyssey вместо pgbouncer в недалёком будущем.

Интересный подход, тоже смотрим в эту сторону. Немного удивляет, что не смотря на AWS вы вообще не стали рассматривать Aurora в качестве альтернативы. Амазон использует Аврору для своих внутренних высоконагруженных кластеров и рекомендует другим.

Про тонкие настройки вопрос скорее в том, нужны ли они? Вы получаете PostgreSQL Cluster «as a service», в котором все настройки уже сделаны «по ключ». Тем не менее, что касается необходимых вам параметров tcp_keepalive, в Авроре они настраиваются.

Обновление PostgreSQL без даунтайма приложения. Необходимо сначала обновить реплики на новую версию, затем сменить лидера в кластере Patroni и обновить старого лидера.

Насколько мне известно такое прокатит только с обновлением на минорные версии. При мажорных бинарная совместимость WAL не гарантируется. Особенно если прыгать через 2 версии. А это значит что при обновлении слейва она уже не сможет получать данные с мастера.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.