Failover PostgreSQL - Quali strumenti devo usare?

Ecco lo scenario:

Esistono due macchine con CentOS 6.2: machine0 e machine1

Entrambi hanno PostgreSQL 9.1 installato.

Uno di questi dovrebbe essere attivo, come sistema principale e attraverso la replica di streaming asincrona sull'altro computer, lo standby dovrebbe copiare le modifiche al database dal sistema principale.

Supponendo che machine0 sia il master e machine1 all'inizio sia lo standby.

Se il master (ad esempio machine0) fallisce (qui l'errore indica che il server Postgresql si arresta in modo anomalo) lo standby dovrebbe subentrare dal master e diventare il nuovo master.

machine1, il nuovo master gestisce tutte le operazioni del database e quando il server postgresql in machine0 torna in linea, dovrebbe diventare uno standby, iniziare la sincronizzazione dal punto in cui ha perso il contatto con machine1 e copiare tutte le modifiche al database e rimanere in modalità standby.

Quando machine1 fallisce, l'intero ciclo si ripete.

Quando lo standby non riesce e torna in linea, dovrebbe iniziare a leggere dal master e sincronizzare i dati.

Sono confuso su quali sono gli strumenti che devo usare per configurarlo, poiché capisco che PostgreSQL non viene fornito con il failover per impostazione predefinita.

Se qualcuno può collegarmi a thread / pagine che descrivono come fare ciò che sto provando, sarò davvero grato.

Se sei interessato alla replica e al failover DB sincroni, ho un suggerimento. Puoi esaminare usando due strumenti:

• DRBD (Disk Replicated Block Device) fornisce la replica a livello del disco (sincrona) tra dischi su due server diversi. Le modifiche al disco vengono replicate sulla rete. È preferibile utilizzare un cavo crossover su eth2 per le schede di rete utilizzando il netblock 192.168.xx.

• ucarp consente la gestione DBVIP e il failover tra due server diversi.

Puoi usarli insieme come segue:

• DBServer1 ha IP 10.1.2.30
• DBServer2 ha IP 10.1.2.40
• DB VIP è 10.1.2.70

Configurare ucarp su due server diversi in modo tale che ciascuna istanza di ucarp comunichi con l'altra tramite un ID router virtuale

DBServer1 avrà

/usr/local/sbin/ucarp -v 200 -p sometagname --interface=eth2 -a 10.1.2.70 -s 10.1.2.30 -b 3 -r 5 --upscript=/usr/local/sbin/vip-up.sh --downscript=/usr/local/sbin/vip-down.sh --neutral -z -B

DBServer2 avrà

/usr/local/sbin/ucarp -v 200 -p sometagname --interface=eth2 -a 10.1.2.70 -s 10.1.2.40 -b 4 -r 5 --upscript=/usr/local/sbin/vip-up.sh --downscript=/usr/local/sbin/vip-down.sh --neutral -z -B

Qual è il motivo -b (trasmissioni) è 3 su un server e 4 sull'altro? Nel caso in cui entrambi i server vengano riavviati, il server con il più basso -b porterà prima ucarp. Per quanto riguarda -r, questo è un rapporto morto. Pertanto, DBServer1 verrà visualizzato in 15 secondi (3X5) e DBServer2 verrà visualizzato in 20 secondi (4X5).

Diciamo che DBServer1 si arresta in modo anomalo. ucarp su DBServer2 verificherà per 20 secondi una stretta di mano da ucarp su DBServer1. Se non viene rilevato nulla, lo script vip-up.sh su DBServer2 prenderà il controllo del DBVIP.

OK, tutto questo è solo per il failover e la gestione DBVIP. Che dire del database PostgreSQL? Sorprendentemente, PostgreSQL funziona solo su un server alla volta. Chiunque abbia il DBVIP dovrebbe avere DRBD in stato primario. Questo si ricollega allo script vip-up. Come lo scrivi?

Ecco lo script /usr/local/sbin/vip-down.sh (concettuale)

#! /bin/sh
exec 2> /dev/null
/sbin/drbdadm disconnect drbd0
/sbin/drbdadm  primary drbd0 &&
/bin/mount postgres-data-folder /mnt/drbd0
/sbin/ip addr add 10.1.2.70/24 dev eth2
/sbin/service postgres start &&
/usr/local/sbin/vipmon.sh &
touch /tmp/vip-up

Ecco lo script /usr/local/sbin/vip-down.sh (concettuale)

#! /bin/sh
exec 2> /dev/null
/sbin/service postgres stop
/bin/umount -l  /dev/drbd0
/sbin/drbdadm secondary drbd0
/sbin/ip addr del 10.1.2.70/24 dev eth2
/bin/rm /tmp/vip-up
/usr/bin/killall -9 ucarp
/usr/local/sbin/vip-down.sh
kill `ps auxww | grep vipmon | awk '{print $2}'`

Tutto quello che devi fare è impostare pg_hba.conf per assicurarti che tutti gli utenti arrivino tramite 10.1.2.70

In sostanza, vip-up esegue questa sequenza

• Fare in modo che DRBD diventi primario
• Montare la cartella dati postgres su / dev / drbd0
• Postgres di avvio
• avviare il processo vipmon

Contrawise, vip-down esegue questa sequenza

• Postgres di spegnimento
• unount / dev / drbd0
• Fare in modo che DRBD diventi secondario

Che dire di vipmon.sh? Potresti copiarlo per controllare, in un ciclo indefinito, lo stato di postgres (è in esecuzione), controllare il dispositivo DRBD (puoi ancora scrivere nella cartella dei dati dei post)

Con questa configurazione, hai Postgres sul DRBD Primario e una copia a livello del disco della cartella dei dati Postgres sull'altro DBServer (il DRBD Secondario). postgres non è in esecuzione sul DRBD Secondary.

Quando si verifica un failover, hai solo bisogno di tempo perché ucarp rilevi che è sicuro montare i dati postgres, avviare postgres e attivare lo script vipmon.

La cosa grandiosa di questa configurazione è che in caso di failover, il DBServer che diventa DRBD Primary dovrebbe avere una copia al 100% a livello di disco del server dal quale non sei riuscito. Quindi iniziare Postgres dovrebbe livellarti in uno stato coerente. I registri delle transazioni (in pg_xlog) devono essere intatti (meno l'intermittenza dovuta al failover)

Spero che questi suggerimenti siano d'aiuto. Anche se sono un DBA MySQL, utilizzo regolarmente MySQL e DRBD presso la società di web hosting del mio datore di lavoro. Ho installato MySQL / DRBD nel modo sopra menzionato. L'ho fatto una volta per un client che utilizza PostgreSQL / DRBD. Funziona benissimo. È open source. Hai solo bisogno di eseguire la dovuta diligenza nell'apprendimento di DRBD e ucarp. Ciò includerebbe la riconnessione di DRBD dopo un failover, la gestione di scenari di split brain in cui entrambi i server DB diventano primari e cose come queste.