Testa la configurazione dell'alta disponibilità

Seleziona una versione della documentazione:

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

Testare 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. Ispeziona i log di Patroni.

    docker compose logs alloydbomni-patroni

    Le ultime voci devono riflettere le informazioni sul nodo Patroni. Dovresti visualizzare un risultato 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 con connettività di rete alla tua istanza Patroni principale, alloydb-patroni1, e ottieni informazioni sull'istanza. Potrebbe essere necessario installare lo strumento jq eseguendo sudo apt-get install jq -y.

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

    Dovresti visualizzare un messaggio 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 API HTTP Patroni su un nodo Patroni espone vari dettagli sullo stato e sulla configurazione di quella particolare istanza PostgreSQL gestita da Patroni, incluse informazioni sullo stato del cluster, sulla cronologia, su WAL e controlli di integrità che indicano se i nodi e il cluster sono attivi e in esecuzione correttamente.

Testare la configurazione di HAProxy

  1. Su una macchina con un browser e connettività di rete al 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 una schermata simile a quella riportata di seguito.

    Pagina di stato di HAProxy che mostra lo stato di integrità e la latenza dei nodi Patroni

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

    Nella dashboard HAProxy puoi visualizzare lo stato di integrità 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 tuo cluster. Da un client come pgAdmin, connettiti al server di database primario tramite HAProxy ed esegui la seguente query.

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

    Dovresti visualizzare un risultato simile al seguente diagramma, che mostra che patroni2 e patroni3 vengono riprodotti in streaming da patroni1.

    Output di pg_stat_replication che mostra lo stato di replica dei nodi Patroni

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

Testare il failover automatico

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

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

    cd /alloydb/

  2. Arresta il container.

    docker compose down

    Dovresti vedere un output simile al seguente. In questo modo viene verificato 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 HAProxy e osserva come avviene il failover.

    Dashboard HAProxy che mostra il failover dal nodo principale al nodo di riserva

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

    L'istanza patroni3 è diventata la nuova istanza primaria e patroni2 è l'unica replica rimanente. Il precedente primario, 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 automatizzata. Non appena il nodo primario 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 primaria. Una volta selezionata una replica candidata, Patroni promuove questo nodo a primario applicando le modifiche necessarie, come l'aggiornamento della configurazione di PostgreSQL e la riproduzione di eventuali record WAL in sospeso. Il nuovo nodo primario aggiorna il sistema di consenso con il suo stato e le altre repliche si riconfigurano per seguire il nuovo nodo primario, cambiando la loro origine di replica e recuperando potenzialmente le nuove transazioni. HAProxy rileva il nuovo nodo primario e reindirizza le connessioni client di conseguenza, 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 un risultato simile al seguente diagramma, che mostra che solo patroni2 è in streaming.

    Output di pg_stat_replication che mostra lo stato di replica dei nodi Patroni dopo il failover

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

  5. Il cluster a tre nodi può sopravvivere a un altro blackout. Se arresti il nodo primario corrente, patroni3, si verifica un altro failover.

    Dashboard HAProxy che mostra il failover dal nodo principale, "patroni3", al nodo di riserva, "patroni2"

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

Considerazioni sul fallback

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

Nel tuo cluster Patroni, se visualizzi i due nodi con cui hai simulato un'interruzione, questi si uniranno nuovamente al cluster come repliche di standby.

Dashboard HAProxy che mostra il ripristino di `patroni1` e `patroni3` come nodi di standby

Immagine 6. Dashboard HAProxy che mostra il ripristino di patroni1 e patroni3 come nodi di standby.

Ora patroni1 e patroni3 vengono replicati dall'istanza principale attuale patroni2.

Output di pg_stat_replication che mostra lo stato di replica dei nodi Patroni dopo il fallback

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

Se vuoi eseguire manualmente il failover sul tuo primario iniziale, puoi farlo utilizzando l'interfaccia a riga di comando patronictl. Se scegli il failover manuale, puoi garantire un processo di recupero più affidabile, coerente e verificato a fondo, mantenendo l'integrità e la disponibilità dei tuoi sistemi di database.