ProHoster > Blog > administracja > Budowanie klastra PostgreSQL o wysokiej dostępności przy użyciu Patroni itp., HAProxy
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:
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
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.
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
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:
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.