Gestire l'elevata disponibilità in PostgreSQL – Parte II:Replication Manager

Stai implementando PostgreSQL nel cloud e vuoi comprendere le tue opzioni per ottenere un'elevata disponibilità? Nel nostro precedente post del blog, Gestione dell'elevata disponibilità in PostgreSQL – Parte I, abbiamo discusso le capacità e il funzionamento di PostgreSQL Automatic Failover (PAF) di ClusterLabs. Nella parte II, ti presentiamo uno strumento open source alternativo, Replication Manager di 2ndQuadrant, a cui seguirà da vicino la Parte III in cui ci immergiamo nella nostra terza alternativa, Patroni di Zalando.

Gestione dell'elevata disponibilità in PostgreSQL – Parte I:Failover automatico di PostgreSQL
Gestire l'alta disponibilità in PostgreSQL – Parte III:Patroni

Gestione repliche (repmgr)

repmgr è una suite di strumenti open source sviluppata da 2ndQuadrant per la gestione della replica e del failover dei cluster PostgreSQL. Fornisce gli strumenti per impostare, configurare, gestire e monitorare la replica di PostgreSQL e consente inoltre di eseguire attività di passaggio e failover manuali utilizzando l'utilità repmgr. Questo strumento gratuito supporta e migliora la replica di streaming integrata di PostgreSQL.

Replication Manager fornisce due strumenti principali per gestire la replica e il failover di PostgreSQL.

repmgr

Un'utilità dell'interfaccia della riga di comando che ti consente di eseguire varie attività amministrative.
repmgr ti consente di configurare server in standby, promuovere standby, eseguire un passaggio e monitorare lo stato del tuo cluster PostgreSQL.
Fornisce anche un'opzione di prova per quasi tutti i comandi amministrativi.

repmgrd

Questo è il demone che:

Controlla attivamente i cluster PostgreSQL ed esegue le azioni necessarie in base allo stato del cluster.
Esegue il failover automatico nel caso in cui il nodo primario si interrompa promuovendo lo standby più idoneo come nuovo primario.
Fornisce un'opzione per monitorare e archiviare i dati relativi alle prestazioni di replica.
Fornisce una notifica richiamando gli script utente per gli eventi registrati.

Come funziona

repmrg non solo gestisce la replica dei cluster PostgreSQL, ma ha anche funzionalità per configurare i server di standby per la replica. Dopo l'installazione iniziale, è necessario apportare modifiche al file di configurazione repmgr (repmgr.conf) con i dettagli richiesti su ciascun server. Quando un server è configurato, deve essere registrato con repmgr utilizzando il comando repmgr primary/standby register. Innanzitutto, il nodo primario viene configurato e registrato. Quindi, i server standby vengono creati e configurati utilizzando il comando repmgr standby clone che clona il nodo standby PostgreSQL da un altro server PostgreSQL.

Replication Manager utilizza la funzionalità delle estensioni di PostgreSQL e crea il proprio schema sul database del cluster per memorizzare le informazioni relative al cluster. L'installazione dell'estensione e la creazione dello schema avviene durante la registrazione del server primario tramite repmgr. Una volta completata l'installazione, è possibile eseguire operazioni amministrative manuali come promuovere, seguire, passare, ecc. utilizzando l'utilità repmgr. Per l'operazione di commutazione, è necessaria la configurazione di SSH senza password tra i nodi.

È possibile impostare il failover automatico utilizzando repmgrd. repmgrd richiede il caricamento di una libreria condivisa "repmgr" al momento dell'avvio del server PostgreSQL. Il nome della libreria dovrebbe essere menzionato nelle librerie_preload_condivise parametro di configurazione nel file postgresql.conf. Inoltre, affinché repmgrd funzioni, failover=automatic il parametro deve essere impostato nel file repmgr.conf. Una volta impostati tutti questi parametri, il daemon repmgrd inizia a monitorare attivamente il cluster. Se si verifica un errore nel nodo primario, proverà a riconnettersi più volte. Quando tutti i tentativi di connessione al primario falliscono, lo standby più idoneo viene scelto dall'elezione come nuovo primario da repmgrd.

repmgr supporta anche le notifiche degli eventi. Ha una serie di eventi predefiniti e memorizza ogni occorrenza di questi eventi nella tabella repmgr.events. repmgr consente di passare le notifiche degli eventi a un programma o uno script definito dall'utente che può intraprendere ulteriori azioni, come l'invio di un'e-mail o l'attivazione di qualsiasi avviso. Questo viene fatto impostando il event_notification_command parametro in repmgr.conf.

Come gestisce lo scenario del cervello diviso?

repmgr affronta scenari di cervelli divisi utilizzando la posizione parametro, in cui ogni nodo deve specificare il parametro di posizione in base al centro dati in cui è posizionato. In caso di divisione della rete, repmgr garantirà la promozione del nodo che si trova nella stessa posizione del primario. Se non trova alcun nodo in quella posizione, non promuoverà alcun nodo in nessuna posizione.

Gestisce anche l'isolamento della rete in caso di un numero pari di server in un cluster. Questo viene fatto utilizzando un nodo aggiuntivo chiamato server di controllo. Il server di controllo è un nodo considerato solo per il conteggio dei voti maggioritari. Non ci sarà alcuna installazione di PostgreSQL su quel server e, quindi, nessun ruolo da svolgere nella replica.

Ci sono dei requisiti di configurazione?

repmgr richiederà un database dedicato e un utente con privilegi di superutente. Tuttavia, c'è anche un'opzione per fornire un superutente se non sei disposto a concedere al superutente l'accesso all'utente repmgr.
Se vuoi che repmgr copi i file di configurazione che si trovano al di fuori della directory dei dati di PostgreSQL e/o per testare la funzionalità di commutazione, avrai anche bisogno di connessioni SSH senza password tra entrambi i server e rsync dovrebbe essere installato.
Se intendi utilizzare comandi basati sul servizio diversi da pg_ctl (che viene utilizzato per impostazione predefinita da repmgr) per avviare, interrompere, ricaricare e riavviare, puoi specificarli in repmgr file di configurazione (repmgr.conf).

I parametri di configurazione di base richiesti nel file di configurazione di repmgr sono i seguenti:

id_nodo (int) – Un numero intero univoco maggiore di zero che identifica il nodo.nome_nodo (stringa) – Si consiglia di utilizzare una stringa arbitraria (ma univoca), utilizzando il nome host del server o un altro identificatore associato al server in modo inequivocabile per evitare confusione.

conninfo (stringa) – Informazioni sulla connessione al database come stringa conninfo. Tutti i server nel cluster devono essere in grado di connettersi al nodo locale utilizzando questa stringa.

directory_dati (stringa) – La directory dei dati del nodo. Questo è necessario a repmgr per eseguire operazioni quando l'istanza PostgreSQL non è in esecuzione e non c'è altro modo per determinare la directory dei dati.

repmgr Pro

Repmgr fornisce utilità che aiutano a configurare i nodi primari e di standby ea configurare la replica.
Non usa porte extra per la comunicazione. Se si desidera eseguire il passaggio, solo allora sarà necessaria la configurazione di SSH senza password.
Fornisce una notifica richiamando gli script utente per gli eventi registrati.
Esegue il failover automatico in caso di guasto del server primario.

repmgr Contro

repmgr non rileva se lo standby è configurato in modo errato con un nodo sconosciuto o inesistente nella configurazione di ripristino. Il nodo verrà mostrato come standby anche se è in esecuzione senza connettersi al nodo standby primario/a cascata.
Impossibile recuperare lo stato di un altro nodo da un nodo in cui il servizio PostgreSQL è inattivo. Pertanto, non fornisce una soluzione di controllo distribuito.
Non gestisce il ripristino della salute dei singoli nodi.

Gestione dell'elevata disponibilità in #PostgreSQL – Parte II:strumento repmgr open source Fai clic per twittare

Scenari di test ad alta disponibilità

Abbiamo condotto alcuni test sulla gestione dell'alta disponibilità di PostgreSQL utilizzando repmgr. Tutti questi test sono stati eseguiti mentre l'applicazione era in esecuzione e inserendo dati nel database PostgreSQL. L'applicazione è stata scritta utilizzando PostgreSQL Java JDBC Driver sfruttando la capacità di failover della connessione.

Test server in standby

Sl. No	Scenario di prova	Osservazione
1	Uccidi il processo PostgreSQL	Il server di standby è stato contrassegnato come guasto. Non si sono verificate interruzioni nell'applicazione dello scrittore. Era necessario un intervento manuale per riavviare il processo PostgreSQL.
2	Interrompi il processo PostgreSQL	Il server di standby è stato contrassegnato come guasto. Non si sono verificate interruzioni nell'applicazione dello scrittore. Era necessario un intervento manuale per riavviare il processo PostgreSQL.
3	Riavvia il server	Il server di standby è stato contrassegnato come guasto. Una volta che il server è stato avviato dopo il riavvio, PostgreSQL è stato avviato manualmente e il server è stato contrassegnato come in esecuzione. Non si sono verificate interruzioni nell'applicazione dello scrittore.
4	Interrompi il processo repmgrd	Il server di standby non farà parte della situazione di failover automatico. È stato riscontrato che il servizio PostgreSQL è in esecuzione. Non si sono verificate interruzioni nell'applicazione dello scrittore.

Test del server principale/primario

Sl. No	Scenario di prova	Osservazione
1	Uccidi il processo PostgreSQL	repmgrd ha avviato il controllo dello stato per la connessione al server primario su tutti i server in standby per un intervallo fisso. Quando tutti i tentativi non sono riusciti, è stata attivata un'elezione su tutti i server di standby. A seguito delle elezioni, lo standby che aveva ricevuto l'ultimo LSN è stato promosso. I server in standby che hanno perso l'elezione attenderanno la notifica dal nuovo nodo master e la seguiranno una volta ricevuta la notifica. Si è verificato un tempo di inattività nell'applicazione di scrittura. È stato necessario un intervento manuale per riavviare il processo PostgreSQL.
2	Interrompi il processo PostgreSQL e ripristinalo immediatamente dopo la scadenza del controllo dello stato	repmgrd ha avviato il controllo dello stato per la connessione al server primario su tutti i server in standby per un intervallo fisso. Quando tutti i tentativi non sono riusciti, è stata attivata un'elezione su tutti i nodi di standby. Tuttavia, il neoeletto master non ha notificato i server di standby esistenti poiché il vecchio master è tornato. Il cluster è stato lasciato in uno stato indeterminato ed è stato necessario un intervento manuale.
3	Riavvia il server	repmgrd ha avviato l'elezione quando il controllo dello stato della connessione principale non è riuscito su tutti i server in standby. Lo standby idoneo è stato promosso. Quando questo server è tornato, non si è unito al cluster ed è stato contrassegnato come non riuscito. Il comando repmgr node rejoin è stato eseguito per aggiungere nuovamente il server al cluster. Si è verificato un tempo di inattività nell'applicazione di scrittura.
4	Interrompi il processo di repmgr	Il server primario non farà parte della situazione di failover automatico. Il servizio PostgreSQL è stato trovato in esecuzione. Non si sono verificate interruzioni nell'applicazione di scrittura.

Test di isolamento della rete

Sl. No	Scenario di prova	Osservazione
1	La rete isola il server primario dagli altri server (hanno tutti lo stesso valore per la posizione nella configurazione repmgr)	repmgrd ha avviato l'elezione quando il controllo dello stato della connessione principale non è riuscito su tutti i server in standby. Lo standby idoneo è stato promosso, ma il processo PostgreSQL era ancora in esecuzione sul vecchio nodo master. C'erano due nodi in esecuzione come master. Dopo la correzione dell'isolamento della rete è stato necessario un intervento manuale.
2	La rete isola il server primario dagli altri server (i server di standby hanno lo stesso valore per la posizione ma il primario aveva un valore diverso per la posizione nella configurazione repmgr)	repmgrd ha avviato l'elezione quando il controllo dello stato della connessione principale non è riuscito su tutti i server in standby. Ma non è stato eletto un nuovo master poiché i server di standby avevano una posizione diversa da quella del primario. repmgrd è entrato in modalità di monitoraggio del degrado. PostgreSQL era in esecuzione su tutti i nodi e c'era un solo master nel cluster.

Inferenza

repmgr fornisce diversi comandi per configurare e monitorare la replica di PostgreSQL. È ricco di funzionalità e facilita anche il lavoro dell'amministratore del database (DBA). Tuttavia, non è uno strumento di gestione dell'alta disponibilità completo poiché non gestirà le risorse. È necessario un intervento manuale per garantire che la risorsa sia in condizioni adeguate.

Quindi, in questo post, abbiamo discusso le capacità e il funzionamento di Replication Manager di 2ndQuadrant. Nel prossimo post parleremo degli stessi aspetti dell'alta disponibilità utilizzando Patroni by Zalando. Per gli utenti che desiderano automatizzare la loro disponibilità elevata nel cloud, dai un'occhiata alle nostre soluzioni completamente gestite PostgreSQL su Azure e PostgreSQL su AWS.