Comments 9
Возможно, потому, что указанные инструменты кластеризации именно 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 это несерьезно. Он не проходит те испытания, которым подвергаются кластеры. Термин "отказоустойчивость" подходит не ко всем решениям в интернете.
«При установке и настройке кластера нам также понадобится пакет csync2. Это пакет синхронизации конфигураций, созданный специально для кластеров» Каких и чьих конфигураций?
Что собой представляет ресурс pg, нужно ли устанавливать пакет resource-agents?
Зачем каждый раз вызывать sudo crm если можно работать в crmsh?
Игорь Косенков:
Отказоустойчивость PostgreSQL обеспечивается за счет отслеживания состояния узлов в кластере и работы PostgreSQL, и автоматического переключения на резервный узел в случае сбоя.
По поводу csync2. Если быть точнее, то утилита предназначена для синхронизации всех необходимых файлов между серверами, эти файлы необязательно д.б. файлами конфигураций. Просто следуя логике, в кластерах изменяемыми файлами являются файлы конфигураций, а не бинарники. Какой смысл синхронизировать бинарники, если они неизменны?
Цель статьи дать понимание каждому действию, поэтому каждая команда приводится отдельно и с пояснениями. Разумеется, после освоения команд crm, удобнее все делать в оболочке crmsh.
То есть csync2 это некий аналог ансибла? Непонятно что именно оно синхронизирует (конфиг постгреса?) Свои конфигурационные файлы на всех нодах пейсмекер обновляет сам, к примеру.
Игорь Косенков:
Управление конфигурацией PostgreSQL доступно частично, только лишь в части, касающейся отказоустойчивости и восстановления. Например, можно менять параметры - archive_command, restore_command, режим синхронности реплик и др. Остальные параметры PostgreSQL меняются как обычно - через конфиг или через консоль psql.
[ответил выше]
Отказоустойчивый кластер PostgreSQL с помощью crm