Шаблон для обеспечения отказоустойчивости кластера PostgreSQL - Patroni (ч. 1)

Я думаю про Patroni слышали если не все, то очень многие. Давайте разберемся, что это такое. В одну заметку всю информацию о Patroni запихнуть невозможно, так что будет цикл заметок.

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

Что же такое Patroni? Patroni - open-source шаблон для разворачивания отказоустойчивого, высокодоступного кластера PostgreSQL на базе потоковой репликации, а также для управления и мониторинга им. Patroni написан на Python. Под капотом Patroni для отказоустойчивости использует потоковую репликацию PostgreSQL, но позволяет автоматизировать переключение между серверами и избежать так называемого split-brain.

Основные возможности Patroni:

Автоматическое переключение узлов в случае аварии на главном;

Ручное переключение узлов или переключение по расписанию;

Поддержка синхронной и асинхронной репликации PostgreSQL;

Поддержка каскадной репликации;

Поддержка автоматического запуска pg_rewind для возврата главного сервере в строй;

Пользовательские скрипты;

REST API для управления и мониторинга кластера Patroni;

Интерфейс командной строки patronictl для управления кластером Patroni.

Теперь, когда мы поняли, что Patroni штука нужная и полезная, давайте разберёмся со схемой его работы и компонентами.

Для работы Patroni необходима распределенная база данных типа ключ-значение. В такой базе Patroni будет хранить состояния узлов и их статус, также нужен прокси-сервер для обеспечения единой точки входа клиента в кластер и переключения клиента на новый мастер сервер. Таким образом, краткое описание схемы работы Patroni получается следующим: агент Patroni устанавливается на всех узлах PostgreSQL, между которыми настроена потоковая репликация. С помощью РБД типа ключ-значение отслеживается состояние узлов, если случилась авария, то Patroni производит автоматическое переключение на сервер реплику и поднимает его роль до главного сервера, а прокси-сервер обеспечивает переключение соединений клиентов на нового мастера.

Если говорить про каждый компонент шаблона Patroni отдельно, то в качестве РБД ключ-значение он поддерживает следующие базы: etcd, Consul, ZooKeeper, и Kubernetes API. Наиболее популярной РБД в связке с Patroni является etcd, а Kubernetes API необходим в случае разворачивания Patroni в Kubernetes. В качестве прокси-сервера вы можете использовать вообще все что угодно, но наиболее популярным тут будет HAProxy.

Собственно РБД обеспечивает Patroni четкие инструкции о том какой сервер является в данный момент главным, а какой репликой. Patroni хранит в РБД ключ типа /leader, который имеет ограниченный TTL (time to live), или по русски срок действия и хранит в себе информацию о текущем мастер сервере. Если ключ не получил своевременного обновления, то Patroni посчитает, что мастер сервер вышел из строя и создаст новый /leader ключ, а также сделает новый мастер сервер из реплики. Все операции с этим ключём защищены работой РБД, которая производит его сравнение на всех узлах кластера, что исключает ситуации когда сразу несколько реплик могут стать мастером и случится split-brain базы данных.

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

Источник: vk.com

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