Построение кластера PostgreSQL высокой доступности с использованием Patroni, etcd, HAProxy

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


Не знаю, в чем загвоздка, но уже в который раз я сталкиваюсь с тем, что даже если делать все пошагово как в туториале, подготовить такой же enviroment как у автора, то все равно никогда ничего не работает. Понятия не имею, в чем тут дело, но когда я столкнулся с этим в очередной раз, я решил — а напишу-ка я свой туториал, когда все получится. Тот, который точно будет работать.


Гайды в Интернете


Так уж вышло, что интернет не страдает от недостатка различных гайдов, туториалов, step-by-step и тому подобных вещей. Так уж вышло, что мне была поставлена задача разработать решение для удобной организации и построения отказоустойчивого кластера PostgreSQL, главными требованиями к которому являлись потоковая репликация с Master-сервера на все реплики и автоматический ввод резерва при отказе Master-сервера.


На этом этапе был определен стек используемых технологий:


  • PostgreSQL в качестве СУБД
  • Patroni в качестве решения для кластеризации
  • etcd в качестве распределенного хранилища для Patroni
  • HAproxy для организации единой точки входа для приложений, использующих базу

Установка


Вашему вниманию — построение кластера PostgreSQL высокой доступности с использованием Patroni, etcd, HAProxy.


Все операции выполнялись на виртуальных машинах с установленной ОС Debian 10.


etcd


Не рекомендую устанавливать etcd на тех же машинах, где будет находится patroni и postgresql, так как для etcd очень важна нагрузка на диски. Но в целях обучения, мы поступим именно так.
Установим etcd.


#!/bin/bash
apt-get update
apt-get install etcd

Добавьте содержимое в файл /etc/default/etcd

[member]


ETCD_NAME=datanode1 # hostname вашей машины
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"


ALL IP ADRESSES SHOULD BE VALID. LISTER PEER, CLIENT etc SHOULD BE SET TO IP ADDRESS OF HOST


ETCD_LISTEN_PEER_URLS="http://192.168.0.143:2380" # адрес вашей машины
ETCD_LISTEN_CLIENT_URLS="http://192.168.0.143:2379,http://127.0.0.1:2379" # адрес вашей машины


[cluster]


ETCD_INITIAL_ADVERTISE_PEER_URLS="http://192.168.0.143:2380" # адрес вашей машины
ETCD_INITIAL_CLUSTER="datanode1=http://192.168.0.143:2380,datanode2=http://192.168.0.144:2380,datanode3=http://192.168.0.145:2380" # адреса всех машин в кластере etcd
ETCD_INITIAL_CLUSTER_STATE="new"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster-1"
ETCD_ADVERTISE_CLIENT_URLS="http://192.168.0.143:2379" # адрес вашей машины


Выполните команду


systemctl restart etcd

PostgreSQL 9.6 + patroni


Первое, что необходимо сделать, это установить три виртуальные машины для установки на них необходимого ПО. После установки машин, если вы следуете моему туториалу, вы можете запустить этот простой скрипт, который (почти) все сделает за вас. Запускается из-под root.


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


#!/bin/bash
apt-get install gnupg -y
echo "deb http://apt.postgresql.org/pub/repos/apt/ buster-pgdg main" >> /etc/apt/sources.list
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | apt-key add -
apt-get update
apt-get install postgresql-9.6 python3-pip python3-dev libpq-dev -y
systemctl stop postgresql
pip3 install --upgrade pip
pip install psycopg2
pip install patroni[etcd]
echo "\
[Unit]
Description=Runners to orchestrate a high-availability PostgreSQL
After=syslog.target network.target

[Service]
Type=simple

User=postgres
Group=postgres

ExecStart=/usr/local/bin/patroni /etc/patroni.yml

KillMode=process

TimeoutSec=30

Restart=no

[Install]
WantedBy=multi-user.targ\
" > /etc/systemd/system/patroni.service
mkdir -p /data/patroni
chown postgres:postgres /data/patroni
chmod 700 /data/patroniпо
touch /etc/patroni.yml

Далее, в созданный только что файл /etc/patroni.yml вам необходимо поместить следующее содержимое, конечно же изменив ip-адреса во всех местах, на адреса, которые используете вы.
Обратите внимание на комментарии в данном yaml. Измените адреса на свои, на каждой машине кластера.


/etc/patroni.yml
scope: pgsql # должно быть одинаковым на всех нодах
namespace: /cluster/ # должно быть одинаковым на всех нодах
name: postgres1 # должно быть разным на всех нодах

restapi:
    listen: 192.168.0.143:8008 # адрес той ноды, в которой находится этот файл
    connect_address: 192.168.0.143:8008 # адрес той ноды, в которой находится этот файл

etcd:
    hosts: 192.168.0.143:2379,192.168.0.144:2379,192.168.0.145:2379 # перечислите здесь все ваши ноды, в случае если вы устанавливаете etcd на них же

# this section (bootstrap) will be written into Etcd:/<namespace>/<scope>/config after initializing new cluster
# and all other cluster members will use it as a `global configuration`
bootstrap:
    dcs:
        ttl: 100
        loop_wait: 10
        retry_timeout: 10
        maximum_lag_on_failover: 1048576
        postgresql:
            use_pg_rewind: true
            use_slots: true
            parameters:
                    wal_level: replica
                    hot_standby: "on"
                    wal_keep_segments: 5120
                    max_wal_senders: 5
                    max_replication_slots: 5
                    checkpoint_timeout: 30

    initdb:
    - encoding: UTF8
    - data-checksums
    - locale: en_US.UTF8
    # init pg_hba.conf должен содержать адреса ВСЕХ машин, используемых в кластере
    pg_hba:
    - host replication postgres ::1/128 md5
    - host replication postgres 127.0.0.1/8 md5
    - host replication postgres 192.168.0.143/24 md5
    - host replication postgres 192.168.0.144/24 md5
    - host replication postgres 192.168.0.145/24 md5
    - host all all 0.0.0.0/0 md5

    users:
        admin:
            password: admin
            options:
                - createrole
                - createdb

postgresql:
    listen: 192.168.0.143:5432 # адрес той ноды, в которой находится этот файл
    connect_address: 192.168.0.143:5432 # адрес той ноды, в которой находится этот файл
    data_dir: /data/patroni # эту директорию создаст скрипт, описанный выше и установит нужные права
    bin_dir:  /usr/lib/postgresql/9.6/bin # укажите путь до вашей директории с postgresql
    pgpass: /tmp/pgpass
    authentication:
        replication:
            username: postgres
            password: postgres
        superuser:
            username: postgres
            password: postgres
    create_replica_methods:
        basebackup:
            checkpoint: 'fast'
    parameters:
        unix_socket_directories: '.'

tags:
    nofailover: false
    noloadbalance: false
    clonefrom: false
    nosync: false

Скрипт необходимо запустить на выполнение на всех трех машинах кластера, точно так же необходимо поместить приведенную конфигурацию в файл /etc/patroni.yml на всех машинах.


Когда вы проделаете эти операции на всех машинах кластера, выполните следующую команду на любой из них


systemctl start patroni
systemctl start postgresql

Подождите около 30 секунд, затем выполните эту команду на остальных машинах кластера.


HAproxy


Мы используем чудесный HAproxy для предоставления единой точки входа. Master-сервер всегда будет доступен по адресу машины, на которой развернут HAproxy.


Для того, чтобы не сделать машину с HAproxy единой точкой отказа, запустим его в контейнере Docker, в дальнейшем его можно будет запустить в кластер K8's и сделать наш отказоустойчивый кластер еще более надежным.


Создайте директорию, где вы сможете хранить два файла — Dockerfile и haproxy.cfg. Перейдите в нее.


Dockerfile
FROM ubuntu:latest

RUN apt-get update \
    && apt-get install -y haproxy rsyslog \
    && rm -rf /var/lib/apt/lists/*

RUN mkdir /run/haproxy

COPY haproxy.cfg /etc/haproxy/haproxy.cfg

CMD haproxy -f /etc/haproxy/haproxy.cfg && tail -F /var/log/haproxy.log

Будьте внимательны, в трех последних строках файла haproxy.cfg должны быть перечислены адреса ваших машин. HAproxy будет обращаться к Patroni, в HTTP-заголовках master-сервер всегда будет возвращать 200, а replica — 503.


haproxy.cfg
global
    maxconn 100

defaults
    log global
    mode tcp
    retries 2
    timeout client 30m
    timeout connect 4s
    timeout server 30m
    timeout check 5s

listen stats
    mode http
    bind *:7000
    stats enable
    stats uri /

listen postgres
    bind *:5000
    option httpchk
    http-check expect status 200
    default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions
    server postgresql1 192.168.0.143:5432 maxconn 100 check port 8008
    server postgresql2 192.168.0.144:5432 maxconn 100 check port 8008
    server postgresql3 192.168.0.145:5432 maxconn 100 check port 8008

Находясь в директории, в которой "лежат" оба наших файла, выполним последовательно команды упаковки контейнера, а также его запуск с пробросом необходимых портов:


docker build -t my-haproxy .
docker run -d -p5000:5000 -p7000:7000 my-haproxy 

Теперь, открыв в браузере адрес вашей машины с HAproxy и указав порт 7000, вы увидите статистику по вашему кластеру.


В состоянии UP будет находится тот сервер, который является мастером, а реплики в состоянии DOWN. Это нормально, на самом деле они работают, но отображаются в таком виде из-за того, что возвращают 503 на запросы от HAproxy. Это позволяет нам всегда точно знать, какой из трех серверов является мастером на данный момент.


Заключение


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


Поздравляю!

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

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

    +3
    Я может чего-то в systemd не понимаю, но как-то странно выглядит заявление о «высокой доступности» и при этом Restart=no в patroni.service. Можете прояснить этот момент?
      0
      Описываемый в статье кластер не стоит запускать на продакшн-серверах с данными, это неоднократно указывается, особенно в части etcd я прямо говорю, что мы с вами сейчас делаем так, а вот вы уже, если решитесь, делайте иначе. Да, этот момент пропустил при написании, конечно стоит изменить этот параметр. Спасибо.
    • НЛО прилетело и опубликовало эту надпись здесь
        +4

        Есть же уже всё с ансиблом и поэтессами:
        https://github.com/vitabaks/postgresql_cluster

          +1
          Более того уже есть такая же статья и куда подробнее habr.com/ru/post/322036
            0
            Увы, это решение не работает.
            +1

            Такого много и моё аналогичное решение (часть, которая касается БД) на ansible не исключение. https://github.com/timlok/otus-highload Patroni/postrgresql 11.6, кластер consul вместо etcd, vip-manager вместо haproxy, пулер соединений odyssey от Яндекса.

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

            Самое читаемое