ProHoster > Blog > administración > Creación de un clúster PostgreSQL de alta disponibilidad utilizando Patroni, etcd, HAProxy
Creación de un clúster PostgreSQL de alta disponibilidad utilizando Patroni, etcd, HAProxy
Dio la casualidad de que en el momento en que surgió el problema, no tenía suficiente experiencia para desarrollar y lanzar esta solución por mi cuenta. Y luego comencé a buscar en Google.
No sé cuál es el problema, pero por enésima vez me enfrento al hecho de que incluso si hago todo paso a paso como en el tutorial, preparo el mismo entorno que el autor, nada funciona. No tengo idea de cuál es el problema, pero cuando me encontré con esto nuevamente, decidí escribir mi propio tutorial cuando todo funcione. Uno que definitivamente funcionará.
Guías en Internet
Da la casualidad de que Internet no carece de varias guías, tutoriales, paso a paso y cosas por el estilo. Dio la casualidad de que se me asignó la tarea de desarrollar una solución para organizar y construir de manera conveniente un clúster PostgreSQL de conmutación por error, cuyos principales requisitos eran la replicación por secuencias desde el servidor maestro a todas las réplicas y el aprovisionamiento automático de una reserva en caso de un servidor maestro. falla.
En esta etapa se determinó el stack de tecnologías utilizadas:
HAproxy para organizar un único punto de entrada para aplicaciones que utilizan la base de datos
Instalación
Para su atención: creación de un clúster PostgreSQL de alta disponibilidad utilizando Patroni, etcd, HAProxy.
Todas las operaciones se realizaron en máquinas virtuales con el sistema operativo Debian 10 instalado.
etcd
No recomiendo instalar etcd en las mismas máquinas donde se ubicarán patroni y postgresql, ya que la carga del disco es muy importante para etcd. Pero con fines educativos, haremos precisamente eso.
Instalemos etcd.
#!/bin/bash
apt-get update
apt-get install etcd
Agregar contenido al archivo /etc/default/etcd
[miembro]
ETCD_NAME=datanode1 # nombre de host de su máquina
ETCD_DATA_DIR=”/var/lib/etcd/default.etcd”
TODAS LAS DIRECCIONES IP DEBEN SER VÁLIDAS. LISTER PEER, CLIENTE, etc. DEBE CONFIGURARSE EN LA DIRECCIÓN IP DEL HOST
Lo primero que debe hacer es configurar tres máquinas virtuales para instalarles el software necesario. Después de instalar las máquinas, si sigues mi tutorial, puedes ejecutar este sencillo script que (casi) hará todo por ti. Se ejecuta como root.
Tenga en cuenta que el script utiliza PostgreSQL versión 9.6, esto se debe a los requisitos internos de nuestra empresa. La solución no ha sido probada en otras versiones de PostgreSQL.
A continuación, en el archivo /etc/patroni.yml que acaba de crear, debe colocar el siguiente contenido, por supuesto cambiando las direcciones IP en todos los lugares a las direcciones que usa.
Presta atención a los comentarios en este yaml. Cambie las direcciones a las suyas en cada máquina del 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
El script debe ejecutarse en las tres máquinas del clúster y la configuración anterior también debe colocarse en el archivo /etc/patroni.yml en todas las máquinas.
Una vez que haya completado estas operaciones en todas las máquinas del clúster, ejecute el siguiente comando en cualquiera de ellas
Espere unos 30 segundos y luego ejecute este comando en las máquinas restantes del clúster.
haproxy
Usamos el maravilloso HAproxy para proporcionar un único punto de entrada. El servidor maestro siempre estará disponible en la dirección de la máquina en la que se implementa HAproxy.
Para no convertir la máquina con HAproxy en un único punto de falla, la lanzaremos en un contenedor Docker; en el futuro podrá iniciarse en el clúster de K8 y hacer que nuestro clúster de conmutación por error sea aún más confiable.
Cree un directorio donde pueda almacenar dos archivos: Dockerfile y haproxy.cfg. Ve hacia eso.
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
Tenga cuidado, las últimas tres líneas del archivo haproxy.cfg deben enumerar las direcciones de sus máquinas. HAproxy se comunicará con Patroni, en los encabezados HTTP el servidor maestro siempre devolverá 200 y la réplica siempre 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 en el directorio en el que se encuentran nuestros dos archivos, ejecutemos secuencialmente los comandos para empaquetar el contenedor, así como ejecutarlo con el reenvío de los puertos necesarios:
Ahora, al abrir la dirección de su máquina con HAproxy en el navegador y especificar el puerto 7000, verá estadísticas de su clúster.
El servidor que es el maestro estará en estado ARRIBA y las réplicas estarán en estado ABAJO. Esto es normal, de hecho funcionan, pero aparecen así porque devuelven 503 para solicitudes de HAproxy. Esto nos permite saber siempre exactamente cuál de los tres servidores es el maestro actual.
Conclusión
¡Eres guapisima! En solo 30 minutos, ha implementado un excelente clúster de base de datos de alto rendimiento y tolerante a fallas con replicación de transmisión y respaldo automático. Si planea utilizar esta solución, consulte con documentación oficial de Patroni, y especialmente con su parte relativa a la utilidad patronictl, que proporciona un acceso conveniente para administrar su clúster.