Article publié le 7 Septembre 2018

Un petit tutoriel sur la manière la plus facile de mettre en place une réplication Master/Slave d’une instance PostgreSQL. Une réplication Master/Slave est extrêmement utile. Elle vous permettra d’avoir un failover et donc une continuité de service en cas de perte de votre master mais également de répartir la charge en redirigeant toute les requête read-only (select) sur votre slave.

Dans ce tutoriel, deux instances PostgreSQL seront installées sur deux machines distinctes.

 La version utilisée lors de la rédaction de ce tutoriel est la version 10.  Si vous utilisez une version différente de postgresql, ce tutoriel sera toujours valable, seul le chemin du répertoire d’installation de postgresql et certaines commandes changeront légèrement.

1)  Configuration du Master

– Éditez votre fichier postgresql.conf (sa localisation diffère en fonction de la distribution et de la version de PostgreSQL installé) et faites les modifications suivantes:

listen_addresses = ‘*’

wal_level = hot_standby

max_wal_senders = <nombre de noeuds dans votre cluster>    # Logiquement 2 dans notre cas master/slave

synchronous_standby_names = ‘<hostname du master>’

wal_keep_segments = 100

– Créez un user dédié à la réplication via cette requête SQL:

create user replica replication;

– Éditez le fichier pg_hba.conf et rajoutez la ligne suivante (permettant ainsi la connexion de votre slave sur votre master):

host     replication     replica     <ip de votre slave>   trust

– Redémarrez enfin votre service PostgreSQL

2) Configuration du Slave

– Arrêtez votre instance PostgreSQL.

– Supprimez tout le contenu du répertoire data situé dans le répertoire d’installation de votre instance PostgreSQL

– Lancez la commande suivante afin d’établir le lien avec votre master:

pg_basebackup -D <pgsql_path>/data -h <ip ou fqdn du master> -U replica

– Éditez ou créez si il n’existe pas déja le fichier recovery.conf situé dans le répertoire data et ajoutez y les lignes suivantes:

standby_mode=on

trigger_file=’/tmp/promotedb’

primary_conninfo=’host=<ip ou fqdn du master> port=5432 user=replica application_name='<valeur de synchronous_standby_name indiqué dans le postgresql.conf du master>’

– Changez le owner du répertoire data (suite à sa précédente suppression celui ci a été recréé avec le user root):

chown -R postgres:postgres <pgsql_path>/data

 hot_standby=on

Afin de rédiger ce tuto j’ai utilisé 2 machines: vdahmane5 comme master et vdahmane6 comme slave.

Pour tester, j’ai créé une nouvelle base de données sur le master:

Je me connecte ensuite sur le slave et vérifie que la création de la base « testreplica » a bien faite:

La réplication fonctionne!

 Attention toutefois, si jamais des données sont directement insérées dans le slave, votre réplication sera par terre. Il vous faudra la reconstuire.

Article publiée le 23 Septembre 2017

Il y a quelque temps, je suis tombé sur la problématique suivante: comment faire en sorte que mon LoadBalancer HAProxy répartisse les connexions sur les machines ayant le moins de charge CPU?

Un collègue m’a alors fait suivre une doc qui m’a apporté la solution.

Ci-dessous un petit tuto vous expliquant comment procéder en prenant comme exemple la répartition d’un flux SSH sur 2 machines. Rien ne vous empêche d’adapter ce tuto  pour rediriger d’autres type de connexion (HTTP, etc…)

1) Configuration de votre serveur HAPROXY

• Installez HAPROXY:

Sous Debian/Ubuntu:

apt-get install haproxy

Sous RedHat/Centos

yum install haproxy

Éditez le fichier /etc/haproxy/haproxy.cfg (pensez à faire une sauvegarde avant) et écrasez le contenu avec la configuration ci-dessous:

global
log 127.0.0.1 local2
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4000
user haproxy
group haproxy
daemon

 

# turn on stats unix socket

stats socket /var/lib/haproxy/stats

 

defaults
mode tcp
log global
option dontlognull
option http-server-close
#option forwardfor except 127.0.0.0/8
option redispatch
retries 3
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s
maxconn 3000

 

 

listen haproxy_servers

#bind correspond au port d’écoute de votre HAPROXY

bind *:2222
mode tcp
option tcplog
timeout client 10800s
timeout server 10800s
#balance leastconn
default-server inter 10s downinter 5s rise 2 fall 2 slowstart 60s maxconn 200 maxqueue 250 weight 100 error-limit 10 on-error mark-down on-marked-down shutdown-sessions agent-port 9707 agent-inter 30s
server monserveur1.mondomaine.net monserveur1.mondomaine.net:22 check agent-check observe layer4
server monserveur2.mondomaine.net monserveur2.mondomaine.net:22 check agent-check observe layer4
server localhost 127.0.0.1:22 maxconn 500 backup weight 1

 

backend servers

mode tcp
option tcplog
#balance roundrobin
server monserveur1.mondomaine.net monserveur1.mondomaine.net:22
server monserveur2.mondomaine.net monserveur2.mondomaine.net:22

2) Installation de l’agent sur les machines hôtes

Déployez l’agent en suivant les instructions ci-dessous sur chacune des machines qui recevra la charge.

• Créez le fichier /usr/local/bin/haproxy-agent-check et insérez le script ci-dessous

#!/bin/bash
LMAX=90

load=$(uptime | grep -E -o ‘load average[s:][: ].*’ | sed ‘s/,//g’ | cut -d’ ‘ -f3-5)
cpus=$(grep processor /proc/cpuinfo | wc -l)

while read -r l1 l5 l15; do {
l5util=$(echo « $l5/$cpus*100″ | bc -l | cut -d ». » -f1);
[[ $l5util -lt $LMAX ]] && echo « up 100% » && exit 0;
[[ $l5util -gt $LMAX ]] && [[ $l5util -lt 100 ]] && echo « up 50% » && exit 0;
echo « down#CPU overload »;
}; done < <(echo $load)

exit 0

• Ajustez les droits pour que le script soit exécutable:

chmod +x /usr/local/bin/haproxy-agent-check

• Installez xinetd (apt-get install xinetd ou yum install xinetd en fonction de votre distribution)
• Éditez le fichier /etc/services et ajoutez y la ligne suivante:

haproxy-agent-check 9707/tcp                # haproxy-agent-check

• Créez le fichier xinetd /etc/xinetd.d/haproxy-agent-check avec le contenu suivant:

# default: on
# description: haproxy-agent-check
service haproxy-agent-check
{
disable         = no
flags           = REUSE
socket_type     = stream
port            = 9707
wait            = no
user            = nobody
server          = /usr/local/bin/haproxy-agent-check
log_on_failure  += USERID
per_source      = UNLIMITED

}

• Ajustez les droits:

chmod +x /etc/xinetd.d/haproxy-agent-check

• Redémarrez le service xinetd

service xinetd restart

• Une fois cette manipulation effectuée sur chacune de vos machine testez la connectivité entre votre serveur HAProxy et vos hôtes via le port 9707

telnet <DNS ou IP de votre machine> 9707

• Redémarrez ensuite le service HaProxy sur la machine prévue à cet effet:

service haproxy restart

• Enfin, depuis votre machine HAproxy, vérifiez que vos agents répondent correctement grâce à la commande suivante:

echo « show stat » | socat stdio unix-connect:/var/lib/haproxy/stats  | cut -d ‘,’ -f1,2,18,19 | grep haproxy

Vous devriez avoir un retour de ce type:

haproxy_servers,FRONTEND,OPEN,
haproxy_servers,<monserveur1>,UP,100
haproxy_servers,<monserveur2>,UP,100
haproxy_servers,localhost,no check,1
haproxy_servers,BACKEND,UP,200

Voila il ne vous reste plus qu’à vous connecter sur votre machines HAPROXY (via la port 2222 dans notre cas) et vous constaterez que votre LoadBalancer répartira la charge sur la machine ayant la charge CPU la plus faible!

Enjoy 😉