Gestione dell'elevata disponibilità di PostgreSQL – Parte I:Failover automatico di PostgreSQL

La gestione dell'alta disponibilità (HA) nel tuo hosting PostgreSQL è un argomento molto importante per garantire che i cluster di distribuzione del database mantengano tempi di attività eccezionali e prestazioni operative elevate in modo che i tuoi dati siano sempre disponibili per la tua applicazione. In un precedente post sul blog, ti abbiamo presentato la configurazione dell'alta disponibilità per PostgreSQL utilizzando la replica in streaming e ora ti mostreremo come gestire al meglio l'elevata disponibilità lato client.

Sono disponibili diversi strumenti per la gestione dell'alta disponibilità (HA) dei cluster di distribuzione PostgreSQL utilizzando la replica in streaming. Queste soluzioni offrono funzionalità di failover automatico, monitoraggio della disponibilità e dello stato del sistema, replica, gestione degli utenti e altre utili attività amministrative sui casi d'uso per i database Postgres. Alcune delle principali soluzioni open source includono:

1. Failover automatico PostgreSQL di ClusterLabs

2. Gestione repliche per cluster PostgreSQL di repmgr (2ndQuadrant)

3. Patroni di Zalando

Ogni strumento fornisce il proprio modo di gestire i cluster PostgreSQL ad alta disponibilità. Nella nostra serie di post in tre parti su HA per PostgreSQL, condivideremo una panoramica, i prerequisiti e i risultati di lavoro e di test per ciascuno di questi tre strumenti. Nella parte 1, approfondiremo la soluzione PAF di ClusterLabs.

• Gestire l'alta disponibilità in PostgreSQL – Parte II:Replication Manager
• Gestire l'alta disponibilità in PostgreSQL – Parte III:Patroni

Come gestire l'alta disponibilità per il tuo database PostgreSQL?

PostgreSQL Automatic Failover (PAF) è una soluzione di gestione della disponibilità elevata per PostgreSQL di ClusterLabs. Utilizza la replica sincrona di Postgres per garantire che nessun dato venga perso al momento dell'operazione di failover. Utilizza il popolare stack Pacemaker e Corosync standard del settore. Con le applicazioni Pacemaker e Corosync insieme, sarai in grado di rilevare gli errori del database PostgreSQL nel sistema e agire di conseguenza.

Pacemaker è un servizio in grado di gestire molte risorse e lo fa con l'aiuto dei loro agenti di risorse. Gli agenti delle risorse hanno quindi la responsabilità di gestire una risorsa specifica, come dovrebbero comportarsi e informare Pacemaker dei loro risultati.

L'implementazione dell'agente di risorse deve essere conforme alla specifica Open Cluster Framework (OCF). Questa specifica definisce il comportamento degli agenti di risorse e l'implementazione di metodi come stop, start, promozione, retrocessione e interazione con Pacemaker.

PAF è un agente di risorse OCF per Postgres scritto in Perl. Una volta che il tuo cluster di database è stato creato utilizzando la replica in streaming interna, PAF è in grado di esporre a Pacemaker lo stato corrente dell'istanza PostgreSQL su ciascuno dei nodi del database:master, slave, arrestato, catch up, load balancer ecc.

Come funziona il failover automatico di Postgres

PAF comunica con Pacemaker in merito allo stato del cluster e monitora il funzionamento del database PostgreSQL. In caso di errore, informa Pacemaker e, se non ci sono possibilità che il master corrente venga ripristinato, attiverà un'elezione tra uno dei server di database in standby correnti. Con il robusto Pacemaker in atto, il failover automatico di Postgres eseguirà azioni di gestione come avvio, arresto, monitoraggio e failover su tutti i nodi dei database Postgres.

Gestione dell'elevata disponibilità in PostgreSQL - Parte I:Failover automatico di ClusterLabsClick To Tweet

Failover automatico di PostgreSQL per la configurazione ad alta disponibilità (HA)

• PAF supporta PostgreSQL versione 9.3 e successive.
• PAF non è responsabile della creazione master/standby di PostgreSQL o della sua configurazione:devi creare e configurare la replica in streaming prima di utilizzare PAF.
• PAF non modifica alcuna configurazione o requisito di configurazione di PostgreSQL. Tuttavia, richiede agli utenti del database di seguire alcuni prerequisiti come:
  • Lo slave deve essere configurato come hot standby. I nodi slave hot standby possono essere interrogati come database di sola lettura.
  • Un file modello di ripristino (predefinito:/recovery.conf.pcmk) deve essere fornito con i parametri seguenti:
    • modalità_attesa =acceso
    • recovery_target_timeline ='ultimo'
    • primary_conninfo deve avere il parametro application_name definito e impostato sul nome del nodo locale come in Pacemaker.
• PAF espone più parametri relativi alla gestione di una risorsa Postgres. Questo può essere configurato in base alle proprie esigenze. Di seguito sono riportati i parametri:
  • rilegatura: posizione dei binari di PostgreSQL (predefinito:/usr/bin)
  • pgdata: posizione del PGDATA della tua istanza (predefinito:/var/lib/pgsql/data)
  • dir dati: percorso della directory impostata in data_directory dal file postgresql.conf
  • pghost: la directory socket o l'indirizzo IP da utilizzare per connettersi all'istanza locale (predefinito:/tmp)
  • pgport: la porta per connettersi all'istanza locale (predefinita:5432)
  • modello_di_recupero: il modello locale che verrà copiato come file PGDATA/recovery.conf. Questo file modello deve esistere su tutti i nodi (predefinito:$PGDATA/recovery.conf.pcmk)
  • opzioni_avvio: Argomenti aggiuntivi forniti al processo Postgres all'avvio. Vedere "postgres –help" per le opzioni disponibili. Utile quando il file postgresql.conf non è nella directory dei dati (PGDATA), es.:-c config_file=/etc/postgresql/9.3/main/postgresql.conf
  • utente_sistema: il proprietario del sistema del processo della tua istanza (predefinito:postgres)
  • ritardo massimo: ritardo massimo consentito in standby prima di impostare un punteggio master negativo su di esso

Professionisti del failover automatico di Postgres

• PAF fornisce all'utente una configurazione e una configurazione pratiche gratuite di PostgreSQL.
• PAF può gestire l'errore del nodo e attivare le elezioni quando il master si interrompe.
• Il comportamento del quorum può essere imposto in PAF.
• Fornirà una soluzione completa di gestione dei database ad alta disponibilità (HA) per la risorsa, inclusi avvio, arresto, monitoraggio e gestione degli scenari di isolamento della rete.
• È una soluzione distribuita, che consente la gestione di qualsiasi nodo da un altro nodo.

Contro del failover automatico di Postgres

• PAF non rileva se un nodo standby è configurato in modo errato 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 standby master/a cascata.
• Richiede l'apertura di una porta aggiuntiva (predefinita 5405) per la comunicazione dei componenti Pacemaker e Corosync tramite UDP.
• Non supporta la configurazione basata su NAT.
• Nessun supporto per pg_rewind.

Alta disponibilità per scenari di test PostgreSQL

Abbiamo condotto alcuni test per determinare la capacità della gestione dell'alta disponibilità (ha) di PostgreSQL utilizzando PAF su alcuni casi d'uso. 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

Test del server principale/primario

Test di isolamento della rete

Test vari

PAF è la soluzione per l'alta disponibilità di PostgreSQL?

Il failover automatico di Postgres offre numerosi vantaggi nella gestione dell'elevata disponibilità (HA) di PostgreSQL in molti casi d'uso. PAF utilizza il failover dell'indirizzo IP invece di riavviare lo standby per connettersi al nuovo master durante un evento di failover. Ciò si rivela vantaggioso negli scenari in cui l'utente non desidera riavviare i nodi di standby. PAF necessita inoltre di un intervento manuale minimo e gestisce lo stato generale di tutte le risorse dei database di Postgres. L'unico caso in cui l'intervento manuale è un requisito è l'eventualità di una divergenza di dati nella sequenza temporale in cui l'utente può scegliere di utilizzare pg_rewind.

Nella parte 1 abbiamo discusso le capacità e il funzionamento di PostgreSQL Automatic Failover (PAF) di ClusterLabs e nella parte 2 ne discuteremo gli stessi aspetti di alta disponibilità utilizzando Replication Manager per i cluster PostgreSQL (repmgr) di 2ndQuadrant. Assicurati di ricontrollare la Parte 3, dove tratteremo anche Patroni di Zalando e confronteremo tutte e tre le soluzioni open source per aiutarti a determinare la soluzione migliore per la tua applicazione.

Nel blog della Parte 1 abbiamo discusso le capacità, le best practice e il funzionamento di PAF di ClusterLabs e nel post del blog della Parte 2 parleremo discutere lo stesso argomento degli aspetti di alta disponibilità utilizzando Replication Manager per i cluster Postgresql (repmgr) di 2ndQuadrant. Assicurati di controllare il nostro post sul blog sulla Parte 3, dove tratteremo anche Patroni di Zalando e confronteremo tutte e tre le soluzioni open source per aiutarti a determinare le best practice e la soluzione ideale per le tue applicazioni aziendali.