Pull to refresh

Comments 9

Скажите, а какая сфера применения у этого монстра, если для промышленной отказоустойчивости есть patroni, а «для дома для семьи» сгодится простенький и легонький repmgr?

Возможно, потому, что указанные инструменты кластеризации именно Postgres и только его, а Pacemaker/Corosync — стек кластера "общего назначения", классический, "кластер по умолчанию" в современных линуксах. И если в компании уже развёрнуто или планируется кластеризовать не только Postgres, то хочется использовать одну общую платформу для всего, чтобы не распыляться, не плодить узких специалистов по тому кластеру и по этому, и так далее.


К тому же, решение по кластеризации PostgreSQL на базе Pacemaker и на самом postgresql.org вполне известно и они на него ссылаются.

Игорь Косенков:

Сфера применения Corosync/Pacemaker такая же, как и у Patroni (и даже шире). Его можно применять не только для СУБД, но и для обеспечения отказоустойчивости любого сервиса. Замечу, что решение, которое Вы назвали "монстром" работает из коробки (если использовать pcs) и требует всего лишь 3 узла в кластере, в то время как, Patroni для обеспечения такого же функционала и тех же параметров отказоустойчивости, как у C/P, требует 2 узла для СУБД + 3 узла для DCS + 2 узла для HA-Proxy. Итого 7 узлов и 4 сервиса (СУБД, Patroni, ETCD, HA-Proxy), которые нужно обслуживать специалистам, обладающим компетенцией. К тому же Patroni не может работать из коробки, необходимо что-то придумать в качестве "точки входа" и обеспечить эту "точку входа" отказоустойчивостью. В качестве точки входа обычно используют HA-Proxy, но его тоже надо резервировать. А что у C/P? Всего лишь 3 узла и 2 сервиса - собственно сам сервис кластера + сервис СУБД. И кто же тут "монстр"? )) repmgr это несерьезно. Он не проходит те испытания, которым подвергаются кластеры. Термин "отказоустойчивость" подходит не ко всем решениям в интернете.

Не раскрыто за счет же чего обеспечивается отказоустойчивость «кластера» Postgres (кластер все же это ноды corosync).
«При установке и настройке кластера нам также понадобится пакет csync2. Это пакет синхронизации конфигураций, созданный специально для кластеров» Каких и чьих конфигураций?
Что собой представляет ресурс pg, нужно ли устанавливать пакет resource-agents?
Зачем каждый раз вызывать sudo crm если можно работать в crmsh?

Игорь Косенков:

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

  2. По поводу csync2. Если быть точнее, то утилита предназначена для синхронизации всех необходимых файлов между серверами, эти файлы необязательно д.б. файлами конфигураций. Просто следуя логике, в кластерах изменяемыми файлами являются файлы конфигураций, а не бинарники. Какой смысл синхронизировать бинарники, если они неизменны?

  3. Цель статьи дать понимание каждому действию, поэтому каждая команда приводится отдельно и с пояснениями. Разумеется, после освоения команд crm, удобнее все делать в оболочке crmsh.

Не описан сам механизм мониторинга и переключения узлов в кластере — по каким параметрам отслеживается состояние узлов (тупо наличие процесса, статус systemd сервиса, какието метрики бд?). Какой тип репликации используется в кластере и по какой схеме проиходит переключении мастера?
То есть csync2 это некий аналог ансибла? Непонятно что именно оно синхронизирует (конфиг постгреса?) Свои конфигурационные файлы на всех нодах пейсмекер обновляет сам, к примеру.
Интересная статья. А как управлять конфигурацией самой PostgreSQL в таком кластере?

Игорь Косенков:

Управление конфигурацией PostgreSQL доступно частично, только лишь в части, касающейся отказоустойчивости и восстановления. Например, можно менять параметры - archive_command, restore_command, режим синхронности реплик и др. Остальные параметры PostgreSQL меняются как обычно - через конфиг или через консоль psql.

Sign up to leave a comment.