Failover e replica PostgreSQL


14

Sto valutando PostgreSQL 9.1 e ho alcune domande relative ai dettagli di failover e replica.

Ho alcuni scenari di test. Il primo con un server master e pochi slave. In caso di crash del Master, voglio che uno degli Slave diventi un Master. Dopo che il Master torna allo stato normale, dovrebbe sincronizzarsi con altri server nel cluster (applicare tutte le modifiche apportate mentre era inattivo) e rivendicare il ruolo Master o diventare uno Slave.

I problemi che vedo con PostgreSQL e lo scenario attuale sono i seguenti.

1) Non vedo gli strumenti integrati per rilevare l'interruzione del server master. Ho letto che pgpool può gestirlo e creare file trigger, ho anche letto che le persone usano il battito cardiaco di Linux o strumenti simili per questo. Bene, posso rilevare il failover e assegnare un nuovo Master nel cluster. Gli altri Slaves capiranno che esiste un nuovo Master e dovrebbero eseguirne il backup adesso?

2) Non capisco la procedura di failback. Le configurazioni host master e slave sono diverse. Quindi avrò due master dopo il crash fail del master? In che modo i server torneranno sincronizzati? Ho visto solo soluzioni manuali come "trasferire la cartella dei dati sul server e riavviarla". Quindi qual è la soluzione o le migliori pratiche o almeno le principali entità qui?

3) Come devo gestire l'interruzione del server sul lato client? Quando creo una connessione, specifico esplicitamente l'IP del server. Devo sviluppare una sorta di ConnectionManager che conoscerà la mia struttura Master-Slave, inviare richieste solo al Master e in caso di perdita della connessione passerò ai server di backup e così via? Ho letto che pgpool può essere un punto di ingresso per le applicazioni e gestire le connessioni in modo corretto. Pgpool è l'unica soluzione qui? Gestisce bene il failover e il failback?

4) Esistono soluzioni (anche commerciali) per evitare di copiare manualmente i dati, riconfigurando le istanze PostgreSQL e altre cose che dovrebbero essere fatte a mano? Quindi, tipo di configurazione del cluster quando tutti sono sincronizzati, è chiaro chi è il Master e tutto cambia automaticamente senza l'attenzione dell'operatore?

Secondo questi thread e articoli

Replica streaming e failover su PostgreSQL

Automatizzare il failover in PostgreSQL 9.1

http://denishjpatel.blogspot.com/2010/11/possibility-of-graceful-switchover.html

non esiste un'unica soluzione completamente automatica per risolvere queste domande. Ho ragione?

Grazie!


Vale probabilmente la pena di fare riferimento ai relativi documenti 9.2 .
Mike Sherrill 'Cat Recall'

Risposte:


4
  1. gli schiavi non capiranno il nuovo padrone. dovresti farlo manualmente.
  2. sì, sono diversi e dovresti crearne di nuovi per il vecchio master. Tuttavia, il vecchio standby continuerà a funzionare come master ma dovresti impostare max_wal_senders su quel nodo. dovresti anche impostare pg_hba.conf del nuovo master dopo il failover. dopo il failover (quando i nodi cambiano i ruoli master-> slave slave-> master), è necessario trasferire i nuovi file wal nella nuova directory di dati delle cartelle di standby impostata nel file recovery.conf. o semplicemente puoi usare rsync.

  3. potrebbe essere possibile utilizzare pgbouncer. in questo modo cambierai semplicemente gli adres del server pgbouncer in nuovo master.

  4. EnterpriseDB ha alcuni strumenti commerciali. potresti essere li puoi controllare.

e finalmente sì hai ragione. non esiste un'unica soluzione completamente automatica per risolvere queste domande.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.