ProHoster > blog > administratie > Bouwen van een zeer beschikbaar PostgreSQL-cluster met behulp van Patroni, etcd, HAProxy
Bouwen van een zeer beschikbaar PostgreSQL-cluster met behulp van Patroni, etcd, HAProxy
Het gebeurde zo dat ik, op het moment dat het probleem werd gesteld, niet genoeg ervaring had om deze oplossing alleen te ontwikkelen en te lanceren. En toen begon ik te Googlen.
Ik weet niet wat de catch is, maar voor de zoveelste keer word ik geconfronteerd met het feit dat zelfs als ik alles stap voor stap doe zoals in de tutorial, dezelfde omgeving voorbereid als de auteur, niets ooit werkt. Ik heb geen idee wat er aan de hand is, maar toen ik dit opnieuw tegenkwam, besloot ik dat ik mijn eigen tutorial zou schrijven als alles lukt. Eén die zeker zal werken.
Gidsen op internet
Het gebeurt zo dat het internet geen last heeft van een gebrek aan verschillende handleidingen, tutorials, stap voor stap en dergelijke. Toevallig kreeg ik de opdracht een oplossing te ontwikkelen voor het gemakkelijk organiseren en bouwen van een failover PostgreSQL-cluster, waarvan de belangrijkste vereisten het streamen van replicatie van de masterserver naar alle replica's waren en het automatisch inrichten van een reserve in het geval van een masterserver. mislukking.
In dit stadium werd de stapel gebruikte technologieën bepaald:
HAproxy voor het organiseren van één enkel toegangspunt voor applicaties die de database gebruiken
installatie
Voor uw aandacht: het bouwen van een zeer beschikbaar PostgreSQL-cluster met behulp van Patroni, etcd, HAProxy.
Alle bewerkingen werden uitgevoerd op virtuele machines waarop Debian 10 OS was geïnstalleerd.
enz
Ik raad niet aan om etcd te installeren op dezelfde machines waarop patroni en postgresql zich zullen bevinden, aangezien schijfbelasting erg belangrijk is voor etcd. Maar voor educatieve doeleinden zullen we precies dat doen.
Laten we etcd installeren.
#!/bin/bash
apt-get update
apt-get install etcd
Voeg inhoud toe aan het bestand /etc/default/etcd
[lid]
ETCD_NAME=datanode1 # hostnaam van uw machine
ETCD_DATA_DIR=”/var/lib/etcd/default.etcd”
ALLE IP-ADRESSEN MOETEN GELDIG ZIJN. LISTER PEER, CLIENT enz. MOETEN WORDEN INGESTELD OP HET IP-ADRES VAN DE HOST
Het eerste dat u hoeft te doen, is drie virtuele machines opzetten en daarop de benodigde software installeren. Als u na het installeren van de machines mijn tutorial volgt, kunt u dit eenvoudige script uitvoeren dat (bijna) alles voor u zal doen. Draait als root.
Houd er rekening mee dat het script PostgreSQL versie 9.6 gebruikt, dit komt door de interne vereisten van ons bedrijf. De oplossing is niet getest op andere versies van PostgreSQL.
Vervolgens moet u in het bestand /etc/patroni.yml dat u zojuist hebt gemaakt de volgende inhoud plaatsen, waarbij u uiteraard de IP-adressen overal wijzigt naar de adressen die u gebruikt.
Let op de opmerkingen in deze yaml. Wijzig de adressen naar uw eigen adressen op elke machine in het cluster.
/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
Het script moet op alle drie de machines van het cluster worden uitgevoerd, en de bovenstaande configuratie moet ook op alle machines in het bestand /etc/patroni.yml worden geplaatst.
Zodra u deze bewerkingen op alle machines in het cluster hebt voltooid, voert u de volgende opdracht op een van deze machines uit
Wacht ongeveer 30 seconden en voer deze opdracht vervolgens uit op de overige machines in het cluster.
HAproxy
We gebruiken de prachtige HAproxy om één enkel toegangspunt te bieden. De masterserver zal altijd beschikbaar zijn op het adres van de machine waarop HAproxy is geïmplementeerd.
Om van de machine met HAproxy geen single point of fail te maken, lanceren we hem in een Docker-container; in de toekomst kan hij in het K8-cluster worden gelanceerd en ons failover-cluster nog betrouwbaarder maken.
Maak een map waarin u twee bestanden kunt opslaan: Dockerfile en haproxy.cfg. Ga ernaar toe.
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
Wees voorzichtig, de laatste drie regels van het haproxy.cfg-bestand moeten de adressen van uw machines vermelden. HAproxy neemt contact op met Patroni, in de HTTP-headers retourneert de masterserver altijd 200 en de replica retourneert altijd 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
Omdat we ons in de map bevinden waarin onze beide bestanden "liggen", voeren we achtereenvolgens de opdrachten uit voor het inpakken van de container, en starten we deze met het doorsturen van de benodigde poorten:
Door nu het adres van uw machine met HAproxy in de browser te openen en poort 7000 op te geven, ziet u statistieken over uw cluster.
De server die de master is, bevindt zich in de UP-status en de replica's bevinden zich in de DOWN-status. Dit is normaal, ze werken in feite, maar ze verschijnen zo omdat ze 503 retourneren voor verzoeken van HAproxy. Hierdoor weten wij altijd precies welke van de drie servers de huidige master is.
Conclusie
Je bent prachtig! In slechts 30 minuten heeft u een uitstekend fouttolerant en krachtig databasecluster geïmplementeerd met streaming-replicatie en automatische fallback. Als u van plan bent deze oplossing te gebruiken, kijk dan eens met officiële Patroni-documentatie, en vooral met zijn deel over het patronictl-hulpprogramma, dat gemakkelijke toegang biedt tot het beheer van uw cluster.