0Pricing
SQL Academy · Lezione

Failover ed elezione del leader (Patroni, Stolon)

Utilizzi Patroni o Stolon per il failover automatico e configuri il quorum per evitare lo split-brain.

Failover ed elezione del leader (Patroni, Stolon) è una lezione SQL Academy gratuita su CoddyKit. Questa è la lezione 3 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento SQL Academy, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso SQL Academy include 4 lezioni in totale.

Perché automatizzare il failover?

Il failover manuale è lento e soggetto a errori. Gli strumenti rilevano il guasto del primario e promuovono una replica senza intervento umano.

Procedura di failover

È necessario:

  1. Rilevare che il primario è inattivo (health check, consenso)
  2. Scegliere la replica con il WAL più recente
  3. Promuoverla (pg_promote / pg_ctl promote)
  4. Riconfigurare le altre repliche affinché seguano il nuovo primario
  5. Aggiornare l'instradamento delle connessioni dell'applicazione

Rischio di split brain

Se la rete si divide, potrebbe promuovere una replica mentre il vecchio primario è ancora attivo. Due primari causerebbero scritture in conflitto e danneggiamento dei dati. Eviti il problema usando un quorum.

Patroni

Daemon Python che usa un DCS esterno (Distributed Configuration Store), in genere etcd, Consul o Zookeeper, per l'elezione del leader:

# patroni.yml
name: pg1
scope: my_cluster
etcd:
  hosts: 10.0.0.10:2379,10.0.0.11:2379,10.0.0.12:2379
postgresql:
  data_dir: /var/lib/postgresql/data

Come Patroni sceglie il nuovo leader

Il daemon Patroni di ogni nodo tenta di acquisire un lock del leader in etcd. Solo uno può detenerlo; quel nodo diventa il primario. Gli altri lo seguono.

Stolon

Alternativa basata su Go. Usa un modello di consenso simile, ma con caratteristiche operative diverse. Suddivide le responsabilità tra i componenti sentinel, keeper e proxy.

repmgr

Strumento più leggero di 2ndQuadrant: offre meno automazione e maggiore controllo manuale. È adatto alle configurazioni più piccole.

Failover gestito dal cloud

RDS, Cloud SQL e Aurora gestiscono il failover al posto Suo. Si rinuncia a una parte della flessibilità in cambio di operazioni più semplici.

Instradamento delle connessioni dopo il failover

Le applicazioni devono conoscere il nuovo primario. Le opzioni sono:

  • Aggiornamento DNS (lento a causa del TTL)
  • IP fluttuante gestito dallo strumento di failover
  • Livello proxy: HAProxy, pgbouncer + script, endpoint AWS RDS

Replica sincrona e failover

Una standby sincrona garantisce l'assenza di perdita di dati. La abbini a un failover automatico per ottenere la massima HA.

Quorum

Per la replica sincrona, imposti synchronous_standby_names con un quorum: devono confermare QUALSIASI 2 repliche su 3. In questo modo una replica lenta o guasta non blocca i commit.

synchronous_standby_names = 'ANY 2 (replica1, replica2, replica3)'

Read-Your-Writes

Dopo un failover o in presenza di ritardo nella replica, un'applicazione potrebbe scrivere sul nuovo primario e leggere subito dati obsoleti da una replica. Instradi le letture successive alle scritture verso il primario oppure usi il monitoraggio di pg_last_wal_replay_lsn.

Testare il failover

Esegua i test prima di averne bisogno. Arresti il primario nell'ambiente di staging ogni mese. Si eserciti con la procedura operativa. Lo stress di un failover reale è già abbastanza elevato; le sorprese lo rendono peggiore.

Riepilogo

Il failover automatico rimuove l'intervento umano da un passaggio critico.

  • Patroni / Stolon per le configurazioni autogestite
  • RDS / Cloud SQL per i servizi gestiti
  • Attenzione allo split brain: usi un quorum
  • Esegua regolarmente prove di failover

Controllo rapido

Che cosa significa "split brain" nel contesto della replica PostgreSQL?

Domande Frequenti

La lezione «Failover ed elezione del leader (Patroni, Stolon)» è gratuita?

Sì — il testo completo di «Failover ed elezione del leader (Patroni, Stolon)» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso SQL Academy, passa a CoddyKit PRO. Il corso SQL Academy include 4 lezioni in totale.

Cosa imparerò in «Failover ed elezione del leader (Patroni, Stolon)»?

Utilizzi Patroni o Stolon per il failover automatico e configuri il quorum per evitare lo split-brain. Eserciti SQL Academy con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare SQL Academy?

Non è richiesta alcuna esperienza precedente. SQL Academy su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 3 di 4.

Quanto tempo richiede la lezione «Failover ed elezione del leader (Patroni, Stolon)»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione SQL Academy?

Sì. Ogni lezione SQL Academy include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Replica streaming e WAL
  2. Replica logica per lo sharding
  3. Failover ed elezione del leader (Patroni, Stolon)
  4. Read replica e instradamento delle connessioni
← Torna a SQL Academy