SQL & éléphant

Les chemins par défaut sont ceux sur CentOS 6, PostgreSQL étant installé depuis les dépôts PGDG. Les instances tourneront sur la même machine sur les ports 9601 et 9602.

Création du maître

sudo -iu postgres /usr/pgsql-9.6/bin/initdb -D /var/lib/pgsql/9.6/I1

Modifier les options suivantes dans postgresql.conf dans ce dernier répertoire :

port = 9601
wallevel = replica 
maxwalsenders = 5 
maxreplication_slots = 5

Dans pg_hba.conf, autoriser la réplication à l’utilisateur postgres en connexion locale sans mot de passe (!) :

local   replication     postgres                                trust

Lancement du maître :

/usr/pgsql-9.6/bin/pg_ctl -D /var/lib/pgsql/9.6/I1 start

Création d’un « slot de réplication » qui évitera de mettre en place l’archivage des journaux de transaction :

psql -p 9601
postgres=# select pgcreatephysicalreplicationslot ('slot_i2') ;

Création de l’esclave

Recopie des fichiers du maître (même si le maître est potentiellement en train de les modifier) :

 /usr/pgsql-9.6/bin/pgbasebackup -D /var/lib/pgsql/9.6/I2/ -X stream -S 'sloti2'
 --checkpoint=fast --verbose --port 9601 --write-recovery-conf

Cette recopie inclut les fichiers de configuration, mais il faut les adapter :

Dans postgresql.conf :

port 9602
hot_standby = on

Un fichier /var/lib/pgsql/9.6/I2/recovery.conf a été créé ; il faut lui rajouter la dernière ligne ;

standbymode = 'on'
primaryconninfo = 'user=postgres port=9601 sslmode=prefer sslcompression=1 krbsrvname=postgres'
primaryslotname = 'sloti2'
recoverytarget_timeline = 'latest'

Démarrage de l’esclave :

/usr/pgsql-9.6/bin/pg_ctl -D /var/lib/pgsql/9.6/I2 start

Contrôler que tout va bien en consultant les logs dans /var/lib/pgsql/9.6/I2/pg_log/.

Fin de la mise en place. Toute création ou modification de données sur le maître doit se répercuter sur l’esclave, qui n’est accessible qu’en lecture seule.

Hors du labo

Pour une mise en prod en conditions réelles, il eût fallu :

• utiliser deux serveurs : la configuration sur une machine n’offre aucun intérêt en sécurité ni performance ;

• intégrer les scripts de démarrage et d’arrêt au système local (ici en Red Hat 6 : dans /etc/init.d/postgresql-9.6-I1 et -I2, compléter /etc/sysconfig/postgresql ou l’usine à gaz qu’est systemd) et sous Debian tenir compte des wrappers qui enrobent pg_ctl ainsi que des chemins différents (postgresql.conf dans /etc/postgresql.conf/9.6/, données dans /val/lib/postgresql, binaires dans /usr/lib/postgresql/9.6/bin/, etc. ) ;

• dans le pg_hba.conf, utiliser un utilisateur dédié à la réplication et surtout avec mot de passe (ici j’ai juste décommenté la partie par défaut dans l’installation sur CentOS, ça ne fonctionne que parce qu’on utilise la même machine pour les deux instances) ;

• éventuellement : configurer un archivage des journaux de transactions (ceux de pg_xlog) dans postgresql.conf : archive_mode = on, archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f' (ou plus complexe et plus sûr…) ; et les récupérer dans l’esclave avec dans recovery.conf la restore_command et éventuellement archivecleanupcommand ; toute choses à intégrer aux sauvegardes PITR (via les journaux de transaction) ;

• configurer éventuellement d’autres paramètres permettant d’utiliser plus sereinement l’esclave quand on requête dessus, notamment hotstandbyfeedback = on, maxstandbyarchive_delay, maxstandbystreaming_delay.