ProHoster > Blog > Administración > Construír un clúster PostgreSQL de alta dispoñibilidade usando Patroni, etcd, HAProxy
Construír un clúster PostgreSQL de alta dispoñibilidade usando Patroni, etcd, HAProxy
Ocorreu que no momento en que se plantexou o problema, non tiña experiencia suficiente para desenvolver e lanzar esta solución só. E entón comecei a buscar en Google.
Non sei cal é a trampa, pero por enésima vez atópome co feito de que aínda que fago todo paso a paso como no titorial, prepare o mesmo ambiente que o autor, entón nada funciona. Non teño nin idea de cal é o problema, pero cando me atopei de novo con isto, decidín escribir o meu propio titorial cando todo funcione. Un que definitivamente funcionará.
Guías en Internet
Dá a casualidade de que Internet non sofre a falta de varias guías, tutoriais, paso a paso e similares. Ocorreu que me encargaron o desenvolvemento dunha solución para organizar e construír de forma cómoda un clúster PostgreSQL de conmutación por fallo, cuxos principais requisitos eran a replicación en streaming desde o servidor mestre a todas as réplicas e o aprovisionamento automático dunha reserva no caso de existir un servidor mestre. fracaso.
Nesta fase, determinouse a pila de tecnoloxías utilizadas:
HAproxy para organizar un único punto de entrada para aplicacións que utilizan a base de datos
Instalación
Para a súa atención: construír un clúster PostgreSQL de alta dispoñibilidade usando Patroni, etcd, HAProxy.
Todas as operacións realizáronse en máquinas virtuais co sistema operativo Debian 10 instalado.
etcd
Non recomendo instalar etcd nas mesmas máquinas onde se atoparán patroni e postgresql, xa que a carga do disco é moi importante para etcd. Pero con fins educativos, faremos exactamente iso.
Imos instalar etcd.
#!/bin/bash
apt-get update
apt-get install etcd
Engade contido ao ficheiro /etc/default/etcd
[membro]
ETCD_NAME=datanode1 # nome de host da túa máquina
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
TODAS LAS DIRECCIÓNS IP DEBEN SER VÁLIDAS. DEBERÍAN CONFIGURAR O IDEAL IP DO ANFITRIÓN LISTER PEER, CLIENTE, etc
O primeiro que cómpre facer é configurar tres máquinas virtuais para instalar nelas o software necesario. Despois de instalar as máquinas, se segues o meu tutorial, podes executar este sinxelo script que (case) fará todo por ti. Funciona como root.
Teña en conta que o script usa a versión 9.6 de PostgreSQL, isto débese aos requisitos internos da nosa empresa. A solución non se probou noutras versións de PostgreSQL.
A continuación, no ficheiro /etc/patroni.yml que acaba de crear, cómpre colocar os seguintes contidos, por suposto cambiando os enderezos IP en todos os lugares polos enderezos que utilice.
Preste atención aos comentarios neste yaml. Cambia os enderezos polos teus propios en cada máquina do clúster.
/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
O script debe executarse nas tres máquinas do clúster e a configuración anterior tamén debe colocarse no ficheiro /etc/patroni.yml en todas as máquinas.
Unha vez que completes estas operacións en todas as máquinas do clúster, execute o seguinte comando en calquera delas
Agarde uns 30 segundos e, a continuación, execute este comando nas máquinas restantes do clúster.
HAproxy
Usamos o marabilloso HAproxy para proporcionar un único punto de entrada. O servidor mestre sempre estará dispoñible no enderezo da máquina na que está implantado HAproxy.
Para non facer que a máquina con HAproxy sexa un único punto de fallo, lanzarémola nun contedor Docker; no futuro pódese lanzar no clúster do K8 e facer que o noso clúster de conmutación por fallo sexa aínda máis fiable.
Crea un directorio onde podes almacenar dous ficheiros: Dockerfile e haproxy.cfg. Vaia a el.
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
Teña coidado, as tres últimas liñas do ficheiro haproxy.cfg deberían enumerar os enderezos das súas máquinas. HAproxy contactará con Patroni, nas cabeceiras HTTP o servidor mestre sempre devolverá 200 e a réplica sempre devolverá 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
Estando no directorio no que "están" os nosos dous ficheiros, executemos secuencialmente os comandos para empaquetar o contenedor, ademais de lanzalo con reenvío dos portos necesarios:
Agora, ao abrir o enderezo da súa máquina con HAproxy no navegador e especificar o porto 7000, verá estatísticas sobre o seu clúster.
O servidor que é o mestre estará no estado UP, e as réplicas estarán no estado DOWN. Isto é normal, de feito funcionan, pero aparecen deste xeito porque devolven 503 para solicitudes de HAproxy. Isto permítenos saber sempre con exactitude cal dos tres servidores é o mestre actual.
Conclusión
Estás preciosa! En só 30 minutos implantou un excelente clúster de bases de datos de alto rendemento e tolerancia a fallos con replicación en tempo real e reserva automática. Se estás a usar esta solución, consulta con documentación oficial de Patroni, e especialmente coa súa parte relativa á utilidade patronictl, que proporciona un acceso cómodo para xestionar o seu clúster.