Postgresql ad oggi con la ultima stabile (9.3) non prevede nativamente un sistema di failover automatico ma rimanda a pgpool o altre terze parti questo sporco lavoro.
Ho pensato di servirmi di uno script bash da far lanciare dal MS SCOM che utilizzano qui, come “recovery cmdline” quando viene recepito un qualsiasi blocco sul nodo master.
L’esigenza degli applicativi, per una serie di situazioni paradossali (!@H#!!!), almeno allo stato attuale è quella di non utilizzare nessun alias/dns ma direttamente gli IP nei connection strings dei propri clients e application server, per questo motivo ho pensato allora di abilitare 2 virtual ip alternativamente su uno o l’altro nodo a secondo della disponibilità recepita da scom.
Nel momento in cui il master sarà giù quindi lo script provvederà a:
1> switcharlo sul primo nodo disponibile abilitando su quest’ultimo i due VIP IP ;
2> syncare le due istanze all’ultima transazione prima del crash
3> risalire il VIP sul nodo READONLY lasciando quello per il READWRITE sul nodo slave diventato MASTER.
Ovviamente tutte le configurazioni si bindano su 0.0.0.0 (in questa maniera le istanze saranno immediatamente disponibili sui VIP senza dover restartare i servizi) oppure, se si preferisce, i listener dovranno riportare staticamente gli ip assegnati. In questo ultimo caso verranno assegnati sui nodi sia gli ip vip che i fisici e sarà obbligatorio un restart dopo ogni assegnazione riportando su ciascun nodo il file recovery.res con la configurazione del file trigger per lo switch di postgresql da slave a master:
standby_mode = ‘on’
primary_conninfo = ‘host=10.1.10.180 port=5432 user=rep password=password_di_rep’
trigger_file = ‘/tmp/postgresql.trigger.5432’
standby_mode = ‘on’
primary_conninfo = ‘host=IP_FISICO_2 port=5432 user=rep password=password_di_rep’
trigger_file = ‘/tmp/postgresql.trigger.5432’
#switch da wpromcavp80 10.11.40.180
#VIP IP RO: 10.11.40.186
#VIP IP RW: 10.11.40.182
PS: ovviamente non sto qui a dilungarmi per spiegarvi cosa e’ un file recovery o un file trigger quando si parla di replica in postgresql … do per scontato che se volete approcciare questa soluzione un po’ esotica e un po’ alchemica 😀 e avventurarvi in questi scripts a seguire.. conoscete gia almeno le basi.
#switch del database
[ -f /tmp/postgresql.trigger.5432 ] && ssh postgres@10.11.40.181 sudo rm /tmp/postgresql.trigger.5432 || echo “Good, filetrigger not found on the remote server…”
#ssh postgres@10.11.40.181 sudo rm /tmp/postgresql.trigger.5432 &&
touch /tmp/postgresql.trigger.5432
#butta giu database e vip ip del master
ssh postgres@10.11.40.181 sudo systemctl stop postgresql-9.5.service &&
ssh postgres@10.11.40.181 sudo /usr/sbin/ifconfig ens192:2 10.11.40.182 down
#tira su vip IP master(RW) qui
sudo ifconfig ens192:1 10.11.40.182 netmask 255.255.255.0 up
#syncronizza lo slave col master
psql -c “;SELECT pg_start_backup(‘backup’, true)” &&
sleep 2
rsync -a -v -e ssh /var/lib/pgsql/9.5/data/ 10.11.40.181:/var/lib/pgsql/9.5/data/ –exclude postmaster.pid –exclude *recovery* –exclude postgresql.conf –exclude *server* –exclude *pg_hba* &&
sleep 2
psql -c “;SELECT pg_stop_backup()” &&
#butta giu IPvip (RO) qui e attiva il nuovo slave db
ssh postgres@10.11.40.181 cp /var/lib/pgsql/9.5/data/recovery.res /var/lib/pgsql/9.5/data/recovery.conf
sudo ifconfig ens192:2 10.11.40.186 down
ssh postgres@10.11.40.181 sudo /usr/sbin/ifconfig ens192:1 10.11.40.186 netmask 255.255.255.0 up &&
sleep 5
ssh postgres@10.11.40.181 sudo /usr/sbin/arping -A -I ens192 10.11.40.186 -w 5
sudo /usr/sbin/arping -A -I ens192 10.11.40.182 -w 5
ssh postgres@10.11.40.181 sudo systemctl start postgresql-9.5.service &&
ssh postgres@10.11.40.181 sudo /usr/sbin/arping -A -I ens192 10.11.40.186 -w 5
sudo /usr/sbin/arping -A -I ens192 10.11.40.182 -w 5
echo $HOSTNAME becomes Master postgresql RW…