Записки программиста

Для PostgreSQL существует множество так называемых high availability решений, наиболее известными из которых, пожалуй, являются repmgr и patroni. Согласно некоторым отзывам, они не слишком удобны в использовании и иногда могут терять данные. Поэтому сегодня мне хотелось бы рассказать о более новом решении под названием Stolon. Разработка Stolon ведется с сентября 2015-го года. Он написан на языке Go, активно паразитирует на Consul или etcd (на выбор пользователя) и из коробки имеет интеграцию с Kubernetes. Но самое главное — он сравнительно прост в использовании и выглядит очень правильно с точки зрения дизайна системы. При правильном использовании Stolon переживает нетсплиты и не теряет данные.

Примечание: Далее предполагается, что читатель знаком с тем, как работает потоковая репликация в PostgreSQL, как происходит переключение на нового мастера, и так далее. Строго говоря, эти знания не являются обязательными для использования Stolon, но они весьма желательны!

Настройка Stolon-кластера

Описанные ниже шаги производились мной на трех Linux-машинах в одной локальной сети с установленными на них PostgreSQL 9.5.4, компилятором языка Go 1.7.1, а также объединенным в кластер Consul’ом версии 0.7.0. Процессы Stolon’а далее будут запускаться прямо из консоли. Настройка их автозапуска не рассматривается. Вы можете настроить его при помощи systemd или, например, runit, как мы это делали в заметке CouchDB 2.0: краткий обзор и мои первые впечатления.

Итак, на всех трех машинах собираем Stolon из исходников:

Запускаем sentinel:

Задача sentinel — следить за состоянием кластера и в случае необходимости производить его реконфигурацию. Одновременно можно запустить сколько угодно sentinel, но из них только один будет выбран, как лидер. Остальные нужны для того, чтобы заменить лидера, если с ним что-то случится. В общем случае, чтобы нормально переживать нетсплиты, следует запускать по одному sentinel на каждой машине с PostgreSQL.

В логах вы увидите что-то вроде:

Это нормально, так как мы еще не запустили ни одного инстанса PostgreSQL. Инстансы в Stolon запускаются через специальную программу-агент под названием keeper. Чтобы запустить первый keeper, создадим файлы, содержащие пароль пользователя postgres и пароль, используемый при репликации:

Теперь запускаем keeper:

В логе sentinel’я увидим:

Сейчас самое время поправить postgresql.conf — увеличить размер shared buffers, и изменить прочие настройки, а затем перезапустить keeper. Stolon поддерживает как синхронную, так и асинхронную репликацию. По умолчанию используется последняя. Настраивать синхронную репликацию сейчас не требуется. Это можно сделать через Stolon и далее будет показано, как.

Следующим шагом запускаем proxy:

Proxy отвечает за пробрасывание TCP-соединения к текущему мастеру и разрыв этого соединения в случае смены мастера. На момент написания этих строк отправка в реплики запросов только на чтение не поддерживается. В связи с этим на практике вы, возможно, решитесь обойтись и без proxy (далее будет показано, как), но для полноты картины давайте все-таки рассмотрим его использование.

Сначала подключаемся к PostgreSQL в обход proxy:

Создаем пользователя и базу данных:

Теперь проверяем подключение через proxy:

Пытаемся выполнить какие-то запросы:

Вроде, работает!

Теперь можно запустить keeper’ы на остальных машинах. Нужно указать другие параметры --id, --pg-listen-address и --listen-address. Пароли следует использовать те же, что и ранее. В логах новых keeper’ов получим что-то вроде:

Как уже отмечалось, по умолчанию Stolon использует асинхронную репликацию. Переключиться на синхронную можно прямо во время работы кластера таким образом:

По аналогии можно переключиться и обратно на асинхронную. В postgresql.conf синхронная репликация выглядит так:

При использовании кластера из трех инстансов PostgreSQL это обеспечивает переживание нетсплитов, так как мастер с одной любой синхронной репликой из списка образуют кворум. Начиная с PostgreSQL 9.6 можно указать точное количество синхронных реплик, но на момент написания этих сток Stolon не использует эту возможность. Это означает, что Stolon может потерять данные, если в кластере больше трех нод и при нетсплите синхронные реплики оказались среди меньшинства.

Проверяем работу автофейловера

Если теперь уронить мастер, в логах sentinel увидим:

В клиенте, использующем proxy, при этом оборвется коннект:

Теперь восстановим postgres1 и сэмулируем нетсплит при помощи iptables на postgres2:

В логах sentinel увидим:

Починим нетсплит и убедимся, что postgres2 вернулся в качестве реплики:

Как видите, Stolon переживает падение машин и нетсплиты. Впрочем, лучше не верьте мне на слово, и проведите собственные, более сложные тесты!

Получение информации о кластере из Consul

Как уже отмечалось, на данный момент proxy не умеет пробасывать запросы только на чтение в реплики. Но ничто не мешает нам найти реплики через Consul самостоятельно и подключиться к ним из приложения напрямую.

Stolon создает не так уж много ключей:

Пример ответа:

Здесь самое интересное — это ключ clusterdata, содержащий всю информацию о кластере:

Ответ довольно размашистый, вы можете ознакомиться с ним здесь. Как видите, все ноды, адреса, порты, роли — все как на ладони!

Напомню, что используя ModifyIndex ключа:

… можно подписаться на его обновления:

Кстати, ключ меняется довольно часто, раз в несколько секунд. Само собой разумеется, эту информацию можно использовать не только для поиска реплик, но и для мониторинга или, например, какой-то визуализации работы кластера.

Заключение

Основные моменты при использовании Stolon:

• Consul или etcd используются исключительно как KV-хранилища. Например, возможность Consul по поиску сервисов через DNS, и прочие специфичные вещи, не используются;
• Если вы хотите создать несколько кластеров Stolon, для нормального переживания нетсплитов и других граничных случаев стоит создать для каждого кластера отдельный кластер Consul’а;
• При промоутинге реплики до мастера Stolon всегда пытается выбрать наилучшую (наименее отставшую) реплику среди доступных. Если в вашем приложении потеря данных недопустима, используйте синхронную репликацию и кластер ровно из трех нод;
• На данный момент запросы через proxy идут только в мастер. Это обещают исправить в версии 0.4.0, а пока что можно обойтись описанным выше воркэраундом;

Многие вопросы, например, использование Stolon вместе с etcd и интеграция с Kubernetes, остались за кадром, но в первом приближении использование Stolon выглядит как-то так. На мой взгляд, Stolon очень многообещающий проект. И работает он именно так, как я сам писал бы автофейловер для PostgreSQL. Только все уже написано.

Дополнение: Вас также может заинтересовать пост Поднимаем кластер CockroachDB из трех нод.

Метки: PostgreSQL, СУБД.