PostgreSQL
 sql >> Database >  >> RDS >> PostgreSQL

Gestire l'elevata disponibilità in PostgreSQL – Parte III:Patroni

Nei post precedenti del blog, abbiamo discusso le capacità e il funzionamento di PostgreSQL Automatic Failover (PAF) di Cluster Labs e Replication Manager (repmgr) di 2ndQuadrant. Nel post finale di questa serie, esamineremo l'ultima soluzione, Patroni di Zalando, e alla fine confronteremo tutte e tre in modo da poter determinare quale framework ad alta disponibilità è il migliore per la tua distribuzione di hosting PostgreSQL.

  • Gestione dell'elevata disponibilità in PostgreSQL – Parte I:Failover automatico di PostgreSQL
  • Gestire l'alta disponibilità in PostgreSQL – Parte II:Replication Manager

Patroni per PostgreSQL

Patroni nasce come fork di Governor, un progetto di Compose. È una suite di strumenti open source, scritta in Python, per la gestione dell'elevata disponibilità dei cluster PostgreSQL. Invece di creare il proprio protocollo di coerenza, Patroni sfrutta in modo intelligente il modello di coerenza fornito da un Distributed Configuration Store (DCS). Supporta anche altre soluzioni DCS come Zookeeper, etcd, Consul e Kubernetes.

Patroni garantisce la configurazione end-to-end dei cluster PostgreSQL HA, inclusa la replica in streaming. Supporta vari modi per creare un nodo di standby e funziona come un modello che può essere personalizzato in base alle tue esigenze.

Questo strumento ricco di funzionalità espone le sue funzionalità tramite le API REST e anche tramite un'utilità della riga di comando chiamata patronictl. Supporta l'integrazione con HAProxy utilizzando le sue API di controllo dello stato per gestire il bilanciamento del carico.

Patroni supporta anche la notifica degli eventi con l'aiuto dei callback, che sono script attivati ​​da determinate azioni. Consente agli utenti di eseguire qualsiasi azione di manutenzione fornendo funzionalità di pausa/ripresa. La funzione di supporto Watchdog rende il framework ancora più robusto.

Come funziona

Inizialmente, è necessario installare i binari PostgreSQL e Patroni. Una volta eseguita questa operazione, sarà necessario configurare anche una configurazione HA DCS. Tutte le configurazioni necessarie per avviare il cluster devono essere specificate nel file di configurazione yaml e Patroni utilizzerà questo file per l'inizializzazione. Sul primo nodo, Patroni inizializza il database, ottiene il leader lock da DCS e garantisce che il nodo venga eseguito come master.

Il passaggio successivo è l'aggiunta di nodi standby, per i quali Patroni fornisce più opzioni. Per impostazione predefinita, Patroni utilizza pg_basebackup per creare il nodo standby e supporta anche metodi personalizzati come WAL-E, pgBackRest, Barman e altri per la creazione del nodo standby. Patroni semplifica l'aggiunta di un nodo di standby e gestisce tutte le attività di bootstrap e la configurazione della replica in streaming.

Gestire l'alta disponibilità in #PostgreSQL – Parte III:Patroni vs. PAF vs. repmgrClick To Tweet

Una volta completata la configurazione del cluster, Patroni monitorerà attivamente il cluster e si assicurerà che sia in uno stato integro. Il nodo master rinnova il blocco leader ogni ttl secondo(i) (predefinito:30 secondi). Quando il nodo master non riesce a rinnovare il leader lock, Patroni attiva un'elezione e il nodo che otterrà il leader lock verrà eletto nuovo master.

Come gestisce lo scenario del cervello diviso?

In un sistema distribuito, il consenso gioca un ruolo importante nel determinare la coerenza e Patroni usa DCS per ottenere il consenso. Solo il nodo che detiene il leader lock può essere il master e il leader lock si ottiene tramite DCS. Se il nodo master non mantiene il blocco leader, verrà immediatamente retrocesso da Patroni per funzionare come standby. In questo modo, in qualsiasi momento, può esserci un solo master in esecuzione nel sistema.

Ci sono dei requisiti di configurazione?

  • Patroni ha bisogno di Python 2.7 e versioni successive.
  • Devono essere installati il ​​DCS e il suo modulo Python specifico. A scopo di test, DCS può essere installato sugli stessi nodi che eseguono PostgreSQL. Tuttavia, in produzione, DCS deve essere installato su nodi separati.
  • Il file di configurazione yaml deve essere presente utilizzando queste impostazioni di configurazione di alto livello:

    Globale/Universale
    Ciò include la configurazione come il nome dell'host (nome) che deve essere univoco per il cluster, il nome del cluster (ambito) e il percorso per l'archiviazione della configurazione in DCS (spazio dei nomi).

    Registro
    Impostazioni di registro specifiche di Patroni inclusi livello, formato, file_num, file_size ecc.

    Configurazione bootstrap
    Questa è la configurazione globale per un cluster che verrà scritto in DCS. Questi parametri di configurazione possono essere modificati con l'aiuto delle API Patroni o direttamente in DCS. La configurazione bootstrap include metodi di creazione standby, parametri initdb, script di post inizializzazione ecc. Contiene anche la configurazione dei timeout, parametri per decidere l'utilizzo delle funzionalità di PostgreSQL come gli slot di replica , modalità sincrona ecc. Questa sezione verrà scritta in ///config di un determinato archivio di configurazione dopo l'inizializzazione del nuovo cluster.

    PostgreSQL
    Questa sezione contiene i parametri specifici di PostgreSQL come l'autenticazione, i percorsi delle directory per i dati, il binario e la configurazione, l'indirizzo IP di ascolto, ecc.

    API REST
    Questa sezione include la configurazione specifica di Patroni relativa alle API REST come indirizzo di ascolto, autenticazione, SSL ecc.

    Consul
    Impostazioni specifiche per Console DCS.

    Etcd
    Impostazioni specifiche per DCS ecc.

    Espositore
    Impostazioni specifiche per Espositore DCS.

    Kubernetes
    Impostazioni specifiche per Kubernetes DCS.

    ZooKeeper
    Impostazioni specifiche di ZooKeeper DCS.

    Watchdog
    Impostazioni specifiche per Watchdog.

Professionisti Patroni

  • Patroni consente la configurazione end-to-end del cluster.
  • Supporta le API REST e l'integrazione HAproxy.
  • Supporta le notifiche di eventi tramite script di callback attivati ​​da determinate azioni.
  • Sfrutta DCS per il consenso.

Patroni Contro

  • Patroni non rileverà l'errata configurazione di uno standby con un nodo sconosciuto o inesistente nella configurazione di ripristino. Il nodo verrà mostrato come slave anche se lo standby è in esecuzione senza connettersi al nodo master/cascading standby.
  • L'utente deve gestire la configurazione, la gestione e l'aggiornamento del software DCS.
  • Richiede l'apertura di più porte per la comunicazione dei componenti:
    • Porta API REST per Patroni
    • Minimo 2 porte per DCS

Scenari di test ad alta disponibilità

Abbiamo condotto alcuni test sulla gestione di PostgreSQL HA utilizzando Patroni. Tutti questi test sono stati eseguiti durante l'esecuzione dell'applicazione e l'inserimento di 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 Patroni ha riportato il processo PostgreSQL allo stato di esecuzione.

  • Non si è verificata alcuna interruzione dell'applicazione di scrittura.
2 Interrompi il processo PostgreSQL Patroni ha riportato il processo PostgreSQL allo stato di esecuzione.

  • Non si è verificata alcuna interruzione dell'applicazione di scrittura.
3 Riavvia il server Patroni deve essere avviato dopo il riavvio, a meno che non sia configurato per non avviarsi al riavvio. Una volta avviato Patroni, ha avviato il processo PostgreSQL e impostato la configurazione di standby.

  • Non si è verificata alcuna interruzione dell'applicazione di scrittura.
4 Interrompi il processo Patroni
  • Non ha interrotto il processo PostgreSQL.
  • elenco patronico non ha mostrato questo server.
  • Non si è verificata alcuna interruzione dell'applicazione di scrittura.

Quindi, in sostanza, è necessario monitorare lo stato di salute del processo Patroni, altrimenti si verificheranno problemi su tutta la linea.

Test del server principale/primario

Sl. No Scenario di prova Osservazione
1 Uccidi il processo PostgreSQL Patroni ha riportato il processo PostgreSQL allo stato di esecuzione. Patroni in esecuzione su quel nodo aveva il blocco primario e quindi l'elezione non è stata attivata.

  • Si è verificato un tempo di inattività nell'applicazione di scrittura.
2 Interrompi il processo PostgreSQL e ripristinalo immediatamente dopo la scadenza del controllo dello stato Patroni ha riportato il processo PostgreSQL allo stato di esecuzione. Patroni in esecuzione su quel nodo aveva il blocco primario e quindi l'elezione non è stata attivata.

  • Si è verificato un tempo di inattività nell'applicazione di scrittura.
3 Riavvia il server Si è verificato un failover e uno dei server in standby è stato eletto nuovo master dopo aver ottenuto il blocco. Quando Patroni è stato avviato sul vecchio master, ha riportato in alto il vecchio master ed ha eseguito pg_rewind e ha iniziato a seguire il nuovo master.T

  • Si è verificato un tempo di inattività nell'applicazione di scrittura.
4 Interrompi/uccidi il processo Patroni
  • Uno dei server in standby ha acquisito il blocco DCS ed è diventato il master promuovendosi.
  • Il vecchio master era ancora in esecuzione e ha portato allo scenario multi-master. La domanda stava ancora scrivendo al vecchio maestro.
  • Una volta che Patroni è stato avviato sul vecchio master, ha riavvolto il vecchio master (use_pg_rewind era impostato su true) alla nuova sequenza temporale principale e lsn e ha iniziato a seguire il nuovo master.

Come puoi vedere sopra, è molto importante monitorare lo stato di salute del processo Patroni sul master. In caso contrario, si può creare uno scenario multi-master e una potenziale perdita di dati.

Test di isolamento della rete

Sl. No Scenario di prova Osservazione
1 Isola dalla rete il server master dagli altri server La comunicazione DCS è stata bloccata per il nodo master.

  • PostgreSQL è stato retrocesso sul server master.
  • Nella partizione di maggioranza è stato eletto un nuovo maestro.
  • Si è verificato un tempo di inattività nell'applicazione di scrittura.
2 Isola dalla rete il server di standby dagli altri server La comunicazione DCS è stata bloccata per il nodo di standby.

  • Il servizio PostgreSQL era in esecuzione, tuttavia, il nodo non è stato preso in considerazione per le elezioni.
  • Non si sono verificate interruzioni nell'applicazione di scrittura.

Qual ​​è il miglior framework HA PostgreSQL?

Patroni è uno strumento prezioso per gli amministratori di database (DBA) PostgreSQL, poiché esegue l'installazione end-to-end e il monitoraggio di un cluster PostgreSQL. La flessibilità di scegliere DCS e la creazione in standby è un vantaggio per l'utente finale, in quanto può scegliere il metodo con cui si sente a proprio agio.

Le API REST, l'integrazione HaProxy, il supporto Watchdog, i callback e la sua gestione ricca di funzionalità rendono Patroni la migliore soluzione per la gestione di PostgreSQL HA.

Test di PostgreSQL HA Framework:PAF vs. repmgr vs. Patroni

Di seguito è inclusa una tabella completa che descrive in dettaglio i risultati di tutti i test che abbiamo eseguito su tutti e tre i framework:PostgreSQL Automatic Failover (PAF), Replication Manager (repmgr) e Patroni.

Test server in standby

Scenario di prova Failover automatico di PostgreSQL (PAF) Replication Manager (repmgr) Patroni
Uccidi il processo PostgreSQL Pacemaker ha riportato il processo PostgreSQL allo stato di esecuzione.

  • Non si è verificata alcuna interruzione dell'applicazione di scrittura.
 Il server di standby è stato contrassegnato come guasto. Era necessario un intervento manuale per riavviare il processo PostgreSQL.

  • Non si è verificata alcuna interruzione dell'applicazione di scrittura.
 Patroni ha riportato il processo PostgreSQL allo stato di esecuzione.

  • Non si è verificata alcuna interruzione dell'applicazione di scrittura.
Interrompi il processo PostgreSQL Pacemaker ha riportato il processo PostgreSQL allo stato di esecuzione.

  • Non si è verificata alcuna interruzione dell'applicazione di scrittura.
 Il server di standby è stato contrassegnato come guasto. Era necessario un intervento manuale per riavviare il processo PostgreSQL.

  • Non si è verificata alcuna interruzione dell'applicazione di scrittura.
 Patroni ha riportato il processo PostgreSQL allo stato di esecuzione.

  • Non si è verificata alcuna interruzione dell'applicazione di scrittura.
Riavvia il server Il server di standby era inizialmente contrassegnato come offline. Una volta che il server è stato avviato dopo il riavvio, PostgreSQL è stato avviato da Pacemaker e il server è stato contrassegnato come online. Se il fencing fosse abilitato, il nodo non sarebbe stato aggiunto automaticamente al cluster.

  • Non si è verificata alcuna interruzione dell'applicazione di scrittura.
 Il server di standby è stato contrassegnato come guasto. Dopo il riavvio del server, PostgreSQL è stato avviato manualmente e il server è stato contrassegnato come in esecuzione.

  • Non si è verificata alcuna interruzione dell'applicazione di scrittura.
 Patroni deve essere avviato dopo il riavvio, a meno che non sia configurato per non avviarsi al riavvio. Una volta avviato Patroni, ha avviato il processo PostgreSQL e impostato la configurazione di standby.

  • Non si è verificata alcuna interruzione dell'applicazione di scrittura.
Interrompi il processo dell'agente framework Agente:pacemaker

  • Il processo PostgreSQL è stato interrotto ed è stato contrassegnato offline.
  • Non si è verificata alcuna interruzione dell'applicazione di scrittura.
 Agente:repmgrd

  • Il server di standby non farà parte della situazione di failover automatico.
  • Il servizio PostgreSQL è stato trovato in esecuzione.
  • Non si è verificata alcuna interruzione dell'applicazione di scrittura.
 Agente:patroni

  • Non ha interrotto il processo PostgreSQL.
  • elenco patronico non ha mostrato questo server.
  • Non si è verificata alcuna interruzione dell'applicazione di scrittura.

Test del server principale/primario

Scenario di prova Failover automatico di PostgreSQL (PAF) Replication Manager (repmgr) Patroni
Uccidi il processo PostgreSQL Pacemaker ha riportato il processo PostgreSQL allo stato di esecuzione. La primaria è stata recuperata entro il tempo limite e quindi l'elezione non è stata attivata.

  • Si è verificato un tempo di inattività nell'applicazione di scrittura.
 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, è stato promosso lo standby che aveva ricevuto l'ultimo LSN. I server in standby che hanno perso l'elezione attenderanno la notifica dal nuovo nodo master e la seguiranno una volta ricevuta la notifica. È stato necessario un intervento manuale per riavviare il processo postgreSQL.

  • Si è verificato un tempo di inattività nell'applicazione di scrittura.
 Patroni ha riportato il processo PostgreSQL allo stato di esecuzione. Patroni in esecuzione su quel nodo aveva il blocco primario e quindi l'elezione non è stata attivata.

  • Si è verificato un tempo di inattività nell'applicazione di scrittura.
Interrompi il processo PostgreSQL e ripristinalo immediatamente dopo la scadenza del controllo dello stato Pacemaker ha riportato il processo PostgreSQL allo stato di esecuzione. Primary got recovered within the threshold time and hence election was not triggered.

  • There was downtime in the writer application.
 repmgrd started health check for primary server connections on all standby servers for a fixed interval. When all the retries failed, an election was triggered on all the standby nodes. However, the newly elected master didn’t notify the existing standby servers since the old master was back.Cluster was left in an indeterminate state and manual intervention was required.

  • There was downtime in the writer application.
 Patroni brought the PostgreSQL process back to running state. Patroni running on that node had primary lock and hence election was not triggered.

  • There was downtime in the writer application.
Reboot the server Election was triggered by Pacemaker after the threshold time for which master was not available. Il server di standby più idoneo è stato promosso come nuovo master. Once the old master came up after reboot, it was added back to the cluster as a standby. If fencing was enabled, then node wouldn’t have been added automatically to cluster.

  • There was downtime in the writer application.
 repmgrd started election when master connection health check failed on all standby servers. The eligible standby was promoted. When this server came back, it didn’t join the cluster and was marked failed. repmgr node rejoin command was run to add the server back to the cluster.

  • There was downtime in the writer application.
 Failover happened and one of the standby servers was elected as the new master after obtaining the lock. When Patroni was started on the old master, it brought back the old master up and performed pg_rewind and started following the new master.

  • There was downtime in the writer application.
Stop the framework agent process Agent:pacemaker

  • The PostgreSQL process was stopped and it was marked offline.
  • Election was triggered and new master was elected.
  • There was downtime in writer application.
 Agent:repmgrd

  • The primary server will not be part of the automated failover situation.
  • PostgreSQL service was found to be running.
  • There was no disruption in writer application.
 Agent:patroni

  • One of the standby servers acquired the DCS lock and became the master by promoting itself.
  • The old master was still running and it led to multi-master scenario. The application was still writing to the old master.
  • Once Patroni was started on the old master, it rewound the old master (use_pg_rewind was set to true) to the new master timeline and lsn and started following the new master.

Test di isolamento della rete

Test Scenario PostgreSQL Automatic Failover (PAF) Replication Manager (repmgr) Patroni
Network isolate the master server from other servers (split brain scenario) Corosync traffic was blocked on the master server.

  • PostgreSQL service was turned off and master server was marked offline due to quorum policy.
  • A new master was elected in the majority partition.
  • There was a downtime in the writer application.
 All servers have the same value for location in repmgr configuration:

  • repmgrd started election when master connection health check failed on all standby servers.
  • The eligible standby was promoted, but the PostgreSQL process was still running on the old master node.
  • There were two nodes running as master. Manual intervention was required after the network isolation was corrected.

The standby servers have the same value for location but the primary had a different value for location in repmgr configuration:

  • repmgrd started election when master connection health check failed on all standby servers.
  • But, there was no new master elected since the standby servers had location different from that of the primary.
  • repmgrd went into degrade monitoring mode. PostgreSQL was running on all the nodes and there was only one master in the cluster.
 DCS communication was blocked for master node.

  • PostgreSQL was demoted on the master server.
  • A new master was elected in the majority partition.
  • There was a downtime in the writer application.
Network-isolate the standby server from other servers Corosync traffic was blocked on the standby server.

  • The server was marked offline and PostgreSQL service was turned off due to quorum policy.
  • There was no disruption in the writer application.
  • repmgrd went into degrade monitoring mode.
  • The PostgreSQL process was still running on the standby node.
  • Manual intervention was required after the network isolation was corrected.
 DCS communication was blocked for the standby node.

  • The PostgreSQL service was running, however, the node was not considered for elections.
  • There was no disruption in the writer application.