Testa la configurazione dell'alta disponibilità

Nota: L'utilizzo di AlloyDB Omni è soggetto al contratto tra te e Google che regola le offerte. Google Cloud Se non disponi di un Google Cloud account o non hai stipulato un contratto con Google che regola le offerte Google Cloud , non procedere o scaricare questo software finché non lo avrai fatto. Per creare un Google Cloud account, consulta la Google Cloud home page.

Garantire l'affidabilità e la qualità della configurazione di Patroni ad alta disponibilità è fondamentale per mantenere le operazioni del database ininterrotte e ridurre al minimo i tempi di riposo. Questa pagina fornisce una guida completa per testare il cluster Patroni, che copre vari scenari di errore, coerenza della replica e meccanismi di failover.

Testa la configurazione di Patroni

1. Connettiti a una delle tue istanze patroni (alloydb-patroni1, alloydb-patroni2 o alloydb-patroni3) e vai alla cartella patroni di AlloyDB Omni.

   cd /alloydb/
   

2. Controlla i log di Patroni.

   docker compose logs alloydbomni-patroni
   

   Le ultime voci devono riflettere le informazioni sul nodo Patroni. Dovresti vedere qualcosa di simile al seguente.

   alloydbomni-patroni        | 2024-06-12 15:10:29,020 INFO: no action. I am (patroni1), the leader with the lock
   alloydbomni-patroni        | 2024-06-12 15:10:39,010 INFO: no action. I am (patroni1), the leader with the lock
   alloydbomni-patroni        | 2024-06-12 15:10:49,007 INFO: no action. I am (patroni1), the leader with the lock
   

3. Connettiti a qualsiasi istanza che esegue Linux e che dispone di connettività di rete con la tua istanza Patroni principale, alloydb-patroni1, e ottieni informazioni sull'istanza. Potresti dover installare lo strumento jq eseguendo sudo apt-get install jq -y.

   curl -s http://alloydb-patroni1:8008/patroni | jq .
   

   Dovresti visualizzare qualcosa di simile al seguente.

   {
     "state": "running",
     "postmaster_start_time": "2024-05-16 14:12:30.031673+00:00",
     "role": "master",
     "server_version": 150005,
     "xlog": {
       "location": 83886408
     },
     "timeline": 1,
     "replication": [
       {
         "usename": "alloydbreplica",
         "application_name": "patroni2",
         "client_addr": "10.172.0.40",
         "state": "streaming",
         "sync_state": "async",
         "sync_priority": 0
       },
       {
         "usename": "alloydbreplica",
         "application_name": "patroni3",
         "client_addr": "10.172.0.41",
         "state": "streaming",
         "sync_state": "async",
         "sync_priority": 0
       }
     ],
     "dcs_last_seen": 1715870011,
     "database_system_identifier": "7369600155531440151",
     "patroni": {
       "version": "3.3.0",
       "scope": "my-patroni-cluster",
       "name": "patroni1"
     }
   }
   

La chiamata all'endpoint dell'API HTTP Patroni su un nodo Patroni mostra vari dettagli sullo stato e sulla configurazione della particolare istanza PostgreSQL gestita da Patroni, tra cui informazioni sullo stato del cluster, sulla sequenza temporale, su WAL e sui controlli di salute che indicano se i nodi e il cluster sono in esecuzione correttamente.

Testa la configurazione di HAProxy

1. Su una macchina con un browser e connettività di rete al tuo nodo HAProxy, vai al seguente indirizzo: http://haproxy:7000. In alternativa, puoi utilizzare l'indirizzo IP esterno dell'istanza HAProxy anziché il relativo nome host.

   Dovresti visualizzare qualcosa di simile allo screenshot seguente.

   

   Figura 1. Pagina dello stato di HAProxy che mostra lo stato di integrità e la latenza dei nodi Patroni.

   Nella dashboard di HAProxy puoi vedere lo stato di salute e la latenza del nodo Patroni principale, patroni1, e delle due repliche, patroni2 e patroni3.

2. Puoi eseguire query per controllare le statistiche di replica nel cluster. Da un client come pgAdmin, connettiti al server del database principale tramite HAProxy ed esegui la seguente query.

   SELECT
         pid, usename, application_name, client_addr, state, sync_state
   FROM
         pg_stat_replication;
   

   Dovresti vedere qualcosa di simile al seguente diagramma, che mostra che patroni2 e patroni3 sono in streaming da patroni1.

   

   Figura 2. Output di pg_stat_replication che mostra lo stato della replica dei nodi Patroni.

Testare il failover automatico

In questa sezione, nel cluster di tre nodi, simuliamo un'interruzione del servizio sul node primario interrompendo il contenitore Patroni in esecuzione collegato. Puoi interrompere il servizio Patroni sul nodo principale per simulare un'interruzione o applicare alcune regole firewall per interrompere la comunicazione con quel nodo.

1. Nell'istanza principale di Patroni, vai alla cartella Patroni di AlloyDB Omni.

   cd /alloydb/
   

2. Interrompi il contenitore.

   docker compose down
   

   Dovresti vedere un output simile al seguente. Dovresti verificare che il contenitore e la rete siano stati arrestati.

   [+] Running 2/2
   ✔ Container alloydb-patroni            Removed
   ✔ Network alloydbomni-patroni_default  Removed
   

3. Aggiorna la dashboard di HAProxy e controlla come viene eseguito il failover.

   

   Figura 3. Dashboard di HAProxy che mostra il failover dal nodo principale al nodo di standby.

   L'istanza patroni3 è diventata la nuova principale e patroni2 è l'unica replica rimanente. Il dominio principale precedente, patroni1, non è attivo e i controlli di integrità non vanno a buon fine.

   Patroni esegue e gestisce il failover tramite una combinazione di monitoraggio, consenso e orchestrazione automatica. Non appena il nodo principale non riesce a rinnovare il lease entro un timeout specificato o se segnala un errore, gli altri nodi del cluster riconoscono questa condizione tramite il sistema di consenso. I nodi rimanenti si coordinano per selezionare la replica più adatta da promuovere come nuova principale. Una volta selezionata una replica candidata, Patroni esegue la promozione di questo nodo a principale applicando le modifiche necessarie, ad esempio aggiornando la configurazione di PostgreSQL e riproducendo eventuali record WAL in sospeso. Il nuovo nodo principale aggiorna il sistema di consenso con il suo stato e le altre repliche si riconfigurano per seguire il nuovo principale, ad esempio cambiando l'origine di replica e potenzialmente recuperando eventuali nuove transazioni. HAProxy rileva il nuovo primario e reindirizza di conseguenza le connessioni dei client, garantendo un'interruzione minima.

4. Da un client come pgAdmin, connettiti al server del database tramite HAProxy e controlla le statistiche di replica nel cluster dopo il failover.

   SELECT
         pid, usename, application_name, client_addr, state, sync_state
   FROM
         pg_stat_replication;
   

   Dovresti vedere qualcosa di simile al seguente diagramma, che mostra che solo patroni2 è in streaming in questo momento.

   

   Figura 4. Output di pg_stat_replication che mostra lo stato della replica dei nodi Patroni dopo il failover.

5. Il cluster di tre nodi può sopravvivere a un'altra interruzione. Se interrompi il nodo primario corrente, patroni3, viene eseguito un altro failover.

   

   Figura 5. Dashboard di HAProxy che mostra il failover dal nodo principale,patroni3, al nodo di riserva, patroni2.

Considerazioni sul fallback

Il failback è il processo di reintegro del precedente nodo di origine dopo un failover. In genere, il fallback automatico non è consigliato in un cluster di database ad alta disponibilità a causa di diversi problemi critici, come il recupero incompleto, il rischio di scenari di split-brain e il ritardo nella replica.

Nel cluster Patroni, se riavvii i due nodi con cui hai simulato un'interruzione, questi si ricongiungeranno al cluster come repliche di standby.

Figura 6. Dashboard di HAProxy che mostra il ripristino di patroni1 e patroni3 come nodi di riserva.

Ora patroni1 e patroni3 eseguono la replica dall'istanza principale attuale patroni2.

Figura 7. Output di pg_stat_replication che mostra lo stato della replica dei nodi Patroni dopo il fallback.

Se vuoi eseguire manualmente il fallback al gruppo principale iniziale, puoi farlo utilizzando l'interfaccia a riga di comando patronictl. Se scegli il fallback manuale, puoi garantire un processo di recupero più affidabile, coerente e verificato in modo accurato, mantenendo l'integrità e la disponibilità dei tuoi sistemi di database.