Alta disponibilità per postgresql

Sono nuovo nel database PostgreSQL. Di recente il nostro sviluppatore ha dovuto eseguire alcuni aggiornamenti nei nostri sistemi.

Per questo motivo stiamo pianificando di implementare alcuni metodi per implementare il failover del database.

Sulla base della mia lettura dalla wiki di postgresql qui , stiamo cercando di implementare warm standby o hot standby. Quindi le mie domande sono:

Quali sono le principali differenze tra loro?
Qual è il migliore?
Esiste un altro metodo che possiamo prendere in considerazione per rendere alta la disponibilità nei nostri database Postgres?

postgresql linux high-availability

— user119720
fonte

Una corretta installazione di heartbeat + STONITH è fondamentale se si prevede di utilizzare il failover automatico. Il failover automatico con un trigger manuale può essere più sicuro. Vedi anche wiki.postgresql.org/wiki/High_Availability

— Craig Ringer

@CraigRinger thanks.Approfondirò quello. Ma quale è in realtà lo standby caldo e caldo? Puoi fornire alcuni dettagli?

— user119720

Risposte:

1 bis. Warm standby è un backup "live", incrementale alimentato con blocchi completi di modifiche (segmenti wal) da 16 mb ciascuno, che vengono inviati al nodo di standby una volta riempiti. Non è possibile eseguire una query su un nodo warm standby. 16 mb di modifiche (per impostazione predefinita) possono significare molte transazioni, se il master fallisce, andranno perse.

1b. Hot Standby . (anche un backup incrementale "live") .piccole modifiche vengono inviate allo slave (record wal, che sono minuscole parti di un segmento wal). È possibile eseguire una query (sola lettura) sul nodo hot standby. La finestra per le transazioni perse in caso di errore del master è molto piccola. Esistono nodi hot standby sincroni e asincroni, un nodo sincrono forzerà il master ad attendere che confermi l'applicazione delle modifiche e quindi il master eseguirà la transazione. Nella replica asincrona il master invia i record wal e non attende la conferma . Il primo richiede un collegamento molto affidabile e veloce tra il master e lo slave, inoltre aggiunge sovraccarico al master ma non garantisce la perdita di dati.

Per quanto riguarda i backup incrementali: 1. Prendi una copia di base dell'intera installazione del database. 2. Spedirlo allo schiavo. 3. Configuralo per recuperare le modifiche.

Streaming Replication (hot standby) è il vincitore qui. Personalmente preferisco la replica asincrona in quanto non impone un onere considerevole al master e il ritardo di replica è molto ridotto (un paio di secondi in molti casi)

Un complemento a questa configurazione è pg-pool. Funziona come proxy tra l'applicazione e i server che partecipano a una configurazione di replica come quella sopra descritta, ha capacità di bilanciamento del carico e query parallele. È anche in grado di fornire failover automatico. http://www.pgpool.net/pgpool-web/contrib_docs/simple_sr_setting/index.html

— Rene Romero Benavides
fonte

Apprezzo molto la tua rapida risposta, che è davvero utile per le mie esigenze. Puoi anche raccomandarmi qualche link giusto per realizzare questa configurazione?

— user119720

certo, dai un'occhiata qui: [link] pgpool.net/pgpool-web/contrib_docs/simple_sr_setting/index.html

— Rene Romero Benavides

Di niente. La curva di apprendimento in queste materie è piuttosto ripida, sii paziente. Buona notte (giorno o qualunque cosa) saluti da Città del Messico.

— Rene Romero Benavides,

Ho fatto alcune ricerche basate sui tuoi link e ci sono domande che mi sono venute in mente. 1. Il warm standby può essere configurato per la replica in streaming? 2. Il pg-pool può essere configurato per il warm standby? 3. Se durante il failover abbiamo configurato il nostro server delle applicazioni che punta al nostro database primario, dobbiamo cambiare la configurazione del database del server delle app in un database slave o lo stesso pg-pool fungerà da proxy per lo slave? Ci scusiamo per il disturbo. Spero non ti dispiaccia.

— user119720

La risposta che hai già ottenuto è un po 'utile, ma termini confusi qui. Tutte le soluzioni di replica integrate utilizzano lo stesso meccanismo di base: copia dei dati di registro write-ahead su un server di standby.

È possibile spostare i dati WAL per la replica in un file da 16 MB alla volta, utilizzando la funzione archive_command o utilizzando Streaming Replication (SR). Se si utilizza SR, è necessario configurare anche l'archiviazione e il server cambierà tra di loro in modo appropriato.

È possibile disporre di un server warm standby, che non può rispondere alle query. Oppure puoi avere un server hot standby, che può rispondere a quelli di sola lettura. Ciò non è correlato al modo in cui i dati vengono messi in standby.

Ognuna di queste due scelte si combina con ognuna delle altre e puoi avere tutte e quattro le combinazioni. È possibile avere un Hot Standby che risponde alle query mentre viene alimentato con il file alla volta segmenti WAL. È possibile avere un server Streaming Replication in cui non è abilitato Hot Standby, quindi non risponderà alle query. È solo che il caso più comune, al giorno d'oggi, è sia Streaming Replication che Hot Standby. Questo è il set completo di funzionalità. Ancora una volta, non ignorare il vecchio meccanismo archive_command solo perché è possibile evitarlo adesso. Può comunque salvarti da errori di streaming che sono altrimenti difficili da recuperare.

— Greg Smith
fonte