Budowanie klastra PostgreSQL o wysokiej dostępności przy użyciu Patroni itp., HAProxy

Tak się złożyło, że w chwili pojawienia się problemu nie miałem wystarczającego doświadczenia, aby samodzielnie opracować i uruchomić to rozwiązanie. A potem zacząłem googlować.

Nie wiem w czym tkwi haczyk, ale po raz kolejny spotykam się z faktem, że nawet jeśli zrobię wszystko krok po kroku jak w tutorialu, przygotuję to samo środowisko co autor, to i tak nic nie zadziała. Nie mam pojęcia, o co chodzi, ale kiedy ponownie się z tym spotkałem, zdecydowałem, że napiszę własny poradnik, gdy wszystko się ułoży. Taki, który na pewno się sprawdzi.

Poradniki w Internecie

Tak się składa, że ​​Internet nie cierpi na brak różnorodnych poradników, tutoriali, krok po kroku i tym podobnych. Tak się złożyło, że dostałem zadanie opracowania rozwiązania umożliwiającego wygodne organizowanie i budowanie awaryjnego klastra PostgreSQL, dla którego głównymi wymaganiami była replikacja strumieniowa z serwera Master do wszystkich replik oraz automatyczne udostępnianie rezerwy w przypadku serwera Master awaria.

Na tym etapie określono stos zastosowanych technologii:

  • PostgreSQL jako system DBMS
  • Patroni jako rozwiązanie klastrowe
  • etcd jako rozproszona pamięć masowa dla Patroni
  • HAproxy do organizacji jednego punktu wejścia dla aplikacji korzystających z bazy danych

Instalacja

Dla Twojej uwagi - budowanie wysoce dostępnego klastra PostgreSQL przy użyciu Patroni itp., HAProxy.

Wszystkie operacje zostały wykonane na maszynach wirtualnych z zainstalowanym systemem operacyjnym Debian 10.

itd

Nie polecam instalowania etcd na tych samych komputerach, na których będą zlokalizowane patroni i postgresql, ponieważ obciążenie dysku jest bardzo ważne dla etcd. Ale zrobimy to w celach edukacyjnych.
Zainstalujmy itp.

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

Dodaj zawartość do pliku /etc/default/etcd

[członek]

ETCD_NAME=datanode1 # nazwa hosta twojej maszyny
ETCD_DATA_DIR=”/var/lib/etcd/default.etcd”

WSZYSTKIE ADRESY IP POWINNY BYĆ WAŻNE. LISTER PEER, CLIENT itp. POWINNY BYĆ USTAWIONE NA ADRES IP HOSTA

ETCD_LISTEN_PEER_URLS="http://192.168.0.143:2380» #adres Twojego samochodu
ETCD_LISTEN_CLIENT_URLS="http://192.168.0.143:2379,http://127.0.0.1:2379» #adres Twojego samochodu

[grupa]

ETCD_INITIAL_ADVERTISE_PEER_URLS="http://192.168.0.143:2380» #adres Twojego samochodu
ETCD_INITIAL_CLUSTER=»datanode1=http://192.168.0.143:2380,datanode2=http://192.168.0.144:2380,datanode3=http://192.168.0.145:2380» # adresy wszystkich komputerów w klastrze etcd
ETCD_INITIAL_CLUSTER_STATE="nowy"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster-1″
ETCD_ADVERTISE_CLIENT_URLS="http://192.168.0.143:2379» #adres Twojego samochodu

Wykonaj polecenie

systemctl restart etcd

PostgreSQL 9.6 + patroni

Pierwszą rzeczą, którą musisz zrobić, to skonfigurować trzy maszyny wirtualne, aby zainstalować na nich niezbędne oprogramowanie. Po zainstalowaniu maszyn, jeśli będziesz postępować zgodnie z moim tutorialem, możesz uruchomić ten prosty skrypt, który (prawie) zrobi wszystko za Ciebie. Działa jako root.

Należy pamiętać, że skrypt korzysta z PostgreSQL w wersji 9.6, wynika to z wewnętrznych wymagań naszej firmy. Rozwiązanie nie było testowane na innych wersjach 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

Następnie w utworzonym właśnie pliku /etc/patroni.yml należy umieścić następującą zawartość, oczywiście zmieniając we wszystkich miejscach adresy IP na adresy, których używasz.
Zwróć uwagę na komentarze w tym yaml. Zmień adresy na własne na każdym komputerze w klastrze.

/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

Skrypt należy uruchomić na wszystkich trzech maszynach klastra, a na wszystkich maszynach powyższą konfigurację należy także umieścić w pliku /etc/patroni.yml.

Po wykonaniu tych operacji na wszystkich komputerach w klastrze uruchom na dowolnym z nich następujące polecenie

systemctl start patroni
systemctl start postgresql

Poczekaj około 30 sekund, a następnie uruchom to polecenie na pozostałych komputerach w klastrze.

HProxy

Używamy wspaniałego HAproxy, aby zapewnić pojedynczy punkt wejścia. Serwer główny będzie zawsze dostępny pod adresem komputera, na którym wdrożono HAproxy.

Aby nie uczynić maszyny z HAproxy pojedynczym punktem awarii, uruchomimy ją w kontenerze Docker, w przyszłości będzie można ją uruchomić w klastrze K8 i jeszcze bardziej zwiększyć niezawodność naszego klastra awaryjnego.

Utwórz katalog, w którym możesz przechowywać dwa pliki - Dockerfile i haproxy.cfg. Idź do tego.

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

Bądź ostrożny, ostatnie trzy linie pliku haproxy.cfg powinny zawierać adresy twoich maszyn. HAproxy skontaktuje się z Patroni, w nagłówkach HTTP serwer główny zawsze zwróci 200, a replika zawsze zwróci 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

Będąc w katalogu, w którym „leżą” oba nasze pliki, wykonajmy po kolei polecenia spakowania kontenera, a także uruchomienia go z przekierowaniem niezbędnych portów:

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

Teraz, otwierając adres swojej maszyny za pomocą HAproxy w przeglądarce i określając port 7000, zobaczysz statystyki dotyczące swojego klastra.

Serwer będący masterem będzie w stanie UP, natomiast repliki będą w stanie DOWN. Jest to normalne, w rzeczywistości działają, ale pojawiają się w ten sposób, ponieważ zwracają 503 dla żądań od HAproxy. Dzięki temu zawsze wiemy dokładnie, który z trzech serwerów jest bieżącym serwerem głównym.

wniosek

Jesteś wspaniały! W ciągu zaledwie 30 minut wdrożyłeś doskonały, odporny na awarie i wydajny klaster baz danych z replikacją strumieniową i automatycznym przywracaniem danych. Jeśli planujesz skorzystać z tego rozwiązania, sprawdź z oficjalną dokumentacją Patroni, a zwłaszcza część dotyczącą narzędzia patronictl, które zapewnia wygodny dostęp do zarządzania klastrem.

Gratulacje!

Źródło: www.habr.com

Dodaj komentarz