Questa pagina è stata tradotta dall'API Cloud Translation.

Architetture per l'alta disponibilità dei cluster PostgreSQL su Compute Engine

Last reviewed 2024-12-03 UTC

Questo documento descrive diverse architetture che forniscono alta disponibilità (HA) per i deployment PostgreSQL su Google Cloud. L'alta disponibilità è la misura della resilienza del sistema in risposta a un errore dell'infrastruttura sottostante. In questo documento, l'alta affidabilità si riferisce alla disponibilità dei cluster PostgreSQL all'interno di una singola regione cloud o tra più regioni, a seconda dell'architettura HA.

Questo documento è rivolto ad amministratori di database, architetti cloud e ingegneri DevOps che vogliono imparare ad aumentare l'affidabilità del livello dati PostgreSQL migliorando il tempo di attività complessivo del sistema. Questo documento illustra i concetti pertinenti all'esecuzione di PostgreSQL su Compute Engine. Il documento non descrive l'utilizzo di database gestiti come Cloud SQL per PostgreSQL e AlloyDB per PostgreSQL.

Se un sistema o un'applicazione richiede uno stato persistente per gestire richieste o transazioni, il livello di persistenza dei dati (il livello dei dati) deve essere disponibile per gestire correttamente le richieste di query o mutazioni dei dati. Il tempo di inattività nel livello di dati impedisce al sistema o all'applicazione di eseguire le attività necessarie.

A seconda degli obiettivi del livello di servizio (SLO) del tuo sistema, potresti richiedere un'architettura che fornisca un livello di disponibilità più elevato. Esiste più di un modo per ottenere l'alta disponibilità, ma in generale si esegue il provisioning di un'infrastruttura ridondante a cui l'applicazione può accedere rapidamente.

Questo documento tratta i seguenti argomenti:

Definizione dei termini relativi ai concetti di database ad alta disponibilità.
Opzioni per le topologie PostgreSQL ad alta disponibilità.
Informazioni contestuali per la valutazione di ogni opzione di architettura.

Terminologia

I seguenti termini e concetti sono standard del settore e sono utili da comprendere per scopi che vanno oltre l'ambito di questo documento.

replica: Il processo mediante il quale le transazioni di scrittura (INSERT, UPDATE o DELETE) e le modifiche allo schema (data definition language (DDL)) vengono acquisite, registrate e poi applicate in serie a tutti i nodi di replica del database downstream nell'architettura.
nodo principale: Il nodo che fornisce una lettura con lo stato più aggiornato dei dati persistenti. Tutte le scritture del database devono essere indirizzate a un nodo primario.
nodo di replica (secondario): Una copia online del nodo del database principale. Le modifiche vengono replicate in modo sincrono o asincrono nei nodi di replica dal nodo primario. Puoi leggere dai nodi di replica sapendo che i dati potrebbero essere leggermente ritardati a causa del ritardo della replica.
ritardo della replica: Una misurazione, in numero di sequenza di log (LSN), ID transazione o tempo. Il ritardo della replica esprime la differenza tra il momento in cui le operazioni di modifica vengono applicate alla replica rispetto al momento in cui vengono applicate al nodo primario.
archiviazione continua: Un backup incrementale in cui il database salva continuamente le transazioni sequenziali in un file.
log write-ahead (WAL): Un log write-ahead (WAL) è un file di log che registra le modifiche ai file di dati prima che vengano effettivamente apportate ai file. In caso di arresto anomalo del server, il WAL è un modo standard per garantire l'integrità e la durabilità dei dati delle tue scritture.
Record WAL: Un record di una transazione applicata al database. Un record WAL viene formattato e archiviato come una serie di record che descrivono le modifiche a livello di pagina del file di dati.
Numero di sequenza di log (LSN): Le transazioni creano record WAL che vengono aggiunti al file WAL. La posizione in cui si verifica l'inserimento è chiamata numero di sequenza di log (LSN). Si tratta di un numero intero a 64 bit, rappresentato da due numeri esadecimali separati da una barra (XXXXXXXX/YYZZZZZZ). "Z" rappresenta la posizione di offset nel file WAL.
file di segmenti: File che contengono il maggior numero possibile di record WAL, a seconda delle dimensioni del file che configuri. I file di segmento hanno nomi di file che aumentano monotonicamente e una dimensione predefinita di 16 MB.
replica sincrona: Una forma di replica in cui il server primario attende che la replica confermi che i dati sono stati scritti nel log delle transazioni della replica prima di confermare un commit al client. Quando esegui la replica in streaming, puoi utilizzare l'opzione synchronous_commit di PostgreSQL, che contribuisce a garantire la coerenza tra il server primario e la replica.
replica asincrona: Una forma di replica in cui il server primario non attende che la replica confermi la ricezione della transazione prima di confermare un commit al client. La replica asincrona ha una latenza inferiore rispetto alla replica sincrona. Tuttavia, se il database principale si arresta in modo anomalo e le transazioni di cui è stato eseguito il commit non vengono trasferite alla replica, esiste la possibilità di perdita di dati. La replica asincrona è la modalità di replica predefinita su PostgreSQL, che utilizza la spedizione dei log basata su file o la replica in streaming.
trasferimento dei log basato su file: Un metodo di replica in PostgreSQL che trasferisce i file di segmento WAL dal server di database principale alla replica. Il servizio primario opera in modalità di archiviazione continua, mentre ogni servizio di standby opera in modalità di recupero continuo per leggere i file WAL. Questo tipo di replica è asincrono.
replica dello streaming: Un metodo di replica in cui la replica si connette all'istanza principale e riceve continuamente una sequenza continua di modifiche. Poiché gli aggiornamenti arrivano tramite un flusso, questo metodo mantiene la replica più aggiornata rispetto all'istanza primaria rispetto alla replica log shipping. Sebbene la replica sia asincrona per impostazione predefinita, puoi configurare in alternativa la replica sincrona.
replica dello streaming fisico: Un metodo di replica che trasferisce le modifiche alla replica. Questo metodo utilizza i record WAL che contengono le modifiche fisiche ai dati sotto forma di indirizzi dei blocchi del disco e modifiche byte per byte.
replica logica in streaming: Un metodo di replica che acquisisce le modifiche in base alla loro identità di replica (chiave primaria), il che consente un maggiore controllo sulla modalità di replica dei dati rispetto alla replica fisica. A causa delle limitazioni nella replica logica di PostgreSQL, la replica logica in streaming richiede una configurazione speciale per una configurazione HA. Questa guida illustra la replica fisica standard e non la replica logica.
uptime: La percentuale di tempo in cui una risorsa funziona ed è in grado di fornire una risposta a una richiesta.
failure detection: Il processo di identificazione di un errore dell'infrastruttura.
failover: Il processo di promozione dell'infrastruttura di backup o standby (in questo caso, il nodo di replica) per diventare l'infrastruttura principale. Durante il failover, il nodo di replica diventa il nodo principale.
switchover: Il processo di esecuzione di un failover manuale su un sistema di produzione. Uno switchover verifica che il sistema funzioni correttamente o rimuove il nodo primario corrente dal cluster per la manutenzione.
Recovery Time Objective (RTO): La durata in tempo reale trascorsa per il completamento del processo di failover del livello di dati. L'RTO dipende dalla quantità di tempo accettabile dal punto di vista aziendale.
Recovery Point Objective (RPO): La quantità di perdita di dati (in tempo reale trascorso) che il livello di dati deve sostenere a seguito del failover. L'RPO dipende dalla quantità di perdita di dati accettabile dal punto di vista aziendale.
di riserva: Il processo di reintegro del nodo primario precedente dopo che la condizione che ha causato un failover è stata risolta.
autoriparazione: La capacità di un sistema di risolvere i problemi senza azioni esterne da parte di un operatore umano.
partizione di rete: Una condizione in cui due nodi di un'architettura, ad esempio i nodi principale e di replica, non possono comunicare tra loro tramite la rete.
split brain: Una condizione che si verifica quando due nodi ritengono contemporaneamente di essere il nodo principale.
gruppo di nodi: Un insieme di risorse di calcolo che forniscono un servizio. In questo documento, questo servizio è il livello di persistenza dei dati.
nodo testimone o quorum: Una risorsa di calcolo separata che aiuta un gruppo di nodi a determinare cosa fare quando si verifica una condizione di split-brain.
elezioni primarie o per la scelta del leader: Il processo mediante il quale un gruppo di nodi peer-aware, inclusi i nodi di controllo, determina quale nodo deve essere il nodo primario.

Quando prendere in considerazione un'architettura HA

Le architetture ad alta disponibilità offrono una maggiore protezione contro i tempi di inattività del livello dati rispetto alle configurazioni di database a singolo nodo. Per selezionare l'opzione migliore per il tuo caso d'uso aziendale, devi comprendere la tua tolleranza ai tempi di inattività e i compromessi rispettivi delle varie architetture.

Utilizza un'architettura HA quando vuoi aumentare l'uptime del livello dati per soddisfare i requisiti di affidabilità per i tuoi carichi di lavoro e servizi. Se il tuo ambiente tollera un certo tempo di inattività, un'architettura HA potrebbe introdurre costi e complessità non necessari. Ad esempio, gli ambienti di sviluppo o test raramente richiedono un'alta disponibilità del livello di database.

Considera i tuoi requisiti per l'alta disponibilità

Di seguito sono riportate diverse domande per aiutarti a decidere quale opzione di alta disponibilità di PostgreSQL è più adatta alla tua attività:

Quale livello di disponibilità speri di raggiungere? Hai bisogno di un'opzione che consenta al tuo servizio di continuare a funzionare solo durante un singolo errore di zona o regionale completo? Alcune opzioni di HA sono limitate a una regione, mentre altre possono essere multiregionali.
Quali servizi o clienti si basano sul tuo livello di dati e qual è il costo per la tua attività in caso di tempi di inattività nel livello di persistenza dei dati? Se un servizio si rivolge solo a clienti interni che richiedono un uso occasionale del sistema, probabilmente ha requisiti di disponibilità inferiori rispetto a un servizio rivolto ai clienti finali che serve i clienti in modo continuo.
Qual è il tuo budget operativo? Il costo è un aspetto importante da considerare: per fornire l'alta disponibilità, i costi dell'infrastruttura e dello spazio di archiviazione aumenteranno probabilmente.
Quanto deve essere automatizzato il processo e con quale rapidità devi eseguire il failover? (Qual è il tuo RTO?) Le opzioni di HA variano in base alla rapidità con cui il sistema può eseguire il failover ed essere disponibile per i clienti.
Puoi permetterti di perdere dati a seguito del failover? (Qual è il tuo RPO?) A causa della natura distribuita delle topologie HA, esiste un compromesso tra la latenza di commit e il rischio di perdita di dati a causa di un errore.

Come funziona l'HA

Questa sezione descrive la replica in streaming e in streaming sincrono che sono alla base delle architetture HA di PostgreSQL.

Replica di streaming

La replica in streaming è un approccio di replica in cui la replica si connette all'istanza principale e riceve continuamente un flusso di record WAL. Rispetto alla replica log shipping, la replica in streaming consente alla replica di rimanere più aggiornata rispetto all'istanza principale. PostgreSQL offre la replica in streaming integrata a partire dalla versione 9. Molte soluzioni HA PostgreSQL utilizzano la replica di streaming integrata per fornire il meccanismo per mantenere sincronizzati più nodi di replica PostgreSQL con il nodo primario. Molte di queste opzioni sono descritte nella sezione Architetture HA di PostgreSQL più avanti in questo documento.

Ogni nodo di replica richiede risorse di calcolo e archiviazione dedicate. L'infrastruttura dei nodi replica è indipendente da quella del nodo principale. Puoi utilizzare i nodi di replica come hot standby per gestire le query client di sola lettura. Questo approccio consente il bilanciamento del carico delle query di sola lettura tra la replica primaria e una o più repliche.

La replica in streaming è asincrona per impostazione predefinita; il server primario non attende una conferma da una replica prima di confermare il commit di una transazione al client. Se un'istanza primaria subisce un errore dopo aver confermato la transazione, ma prima che una replica riceva la transazione, la replica asincrona può comportare una perdita di dati. Se la replica viene promossa a nuova primaria, questa transazione non sarà presente.

Replica sincrona dello streaming

Puoi configurare la replica in streaming come sincrona scegliendo una o più repliche da utilizzare come standby sincrono. Se configuri l'architettura per la replica sincrona, il database primario non conferma il commit di una transazione finché la replica non riconosce la persistenza della transazione. La replica in streaming sincrona offre una maggiore durabilità in cambio di una latenza delle transazioni più elevata.

L'opzione di configurazione synchronous_commit ti consente anche di configurare i seguenti livelli di durabilità delle repliche progressive per la transazione:

local: le repliche di standby sincrone non sono coinvolte nella conferma del commit. Il server primario riconosce i commit delle transazioni dopo che i record WAL vengono scritti e scaricati sul disco locale. I commit delle transazioni sull'istanza principale non coinvolgono le repliche di standby. Le transazioni possono andare perse se si verifica un errore sul server primario.
on [impostazione predefinita]: le repliche di standby sincrone scrivono le transazioni di cui è stato eseguito il commit nel WAL prima di inviare l'acknowledgement al database primario. L'utilizzo della configurazione on garantisce che la transazione possa essere persa solo se l'archivio primario e tutte le repliche di standby sincrone subiscono errori di archiviazione simultanei. Poiché le repliche inviano un riconoscimento solo dopo aver scritto i record WAL, i client che eseguono query sulla replica non vedranno le modifiche finché i rispettivi record WAL non vengono applicati al database della replica.
remote_write: le repliche di standby sincrone confermano la ricezione del record WAL a livello di sistema operativo, ma non garantiscono che il record WAL sia stato scritto su disco. Poiché remote_write non garantisce la scrittura del WAL, la transazione può andare persa in caso di errore sia nell'istanza primaria che in quella secondaria prima che i record vengano scritti. remote_write ha una durata inferiore rispetto all'opzione on.
remote_apply: le repliche di standby sincrone confermano la ricezione della transazione e l'applicazione riuscita al database prima di confermare il commit della transazione al client. L'utilizzo della configurazione remote_apply garantisce che la transazione venga salvata nella replica e che i risultati della query client includano immediatamente gli effetti della transazione. remote_apply offre maggiore durabilità e coerenza rispetto a on e remote_write.

L'opzione di configurazione synchronous_commit funziona con l'opzione di configurazione synchronous_standby_names che specifica l'elenco dei server di standby che partecipano al processo di replica sincrona. Se non vengono specificati nomi di standby sincroni, i commit delle transazioni non attendono la replica.

Architetture HA di PostgreSQL

Al livello più elementare, l'HA del livello di dati consiste in quanto segue:

Un meccanismo per identificare se si verifica un errore del nodo primario.
Un processo per eseguire un failover in cui il nodo di replica viene promosso a nodo primario.
Un processo per modificare il routing delle query in modo che le richieste dell'applicazione raggiungano il nuovo nodo primario.
(Facoltativo) Un metodo per eseguire il failback all'architettura originale utilizzando i nodi principali e di replica pre-failover nelle loro capacità originali.

Le sezioni seguenti forniscono una panoramica delle seguenti architetture HA:

Il modello Patroni
Estensione e servizio pg_auto_failover
Gruppi di istanze gestite stateful e disco permanente regionale

Queste soluzioni HA riducono al minimo i tempi di inattività in caso di interruzione dell'infrastruttura o della zona. Quando scegli tra queste opzioni, bilancia la latenza di commit e la durabilità in base alle esigenze della tua attività.

Un aspetto fondamentale di un'architettura di alta affidabilità è il tempo e lo sforzo manuale necessari per preparare un nuovo ambiente di standby per il successivo failover o fallback. In caso contrario, il sistema può resistere a un solo errore e il servizio non è protetto da una violazione dello SLA. Ti consigliamo di selezionare un'architettura HA in grado di eseguire failover manuali o switchover con l'infrastruttura di produzione.

HA using the Patroni template

Patroni è un modello di software open source (con licenza MIT) maturo e sottoposto a manutenzione attiva che fornisce gli strumenti per configurare, eseguire il deployment e gestire un'architettura HA PostgreSQL. Patroni fornisce uno stato del cluster condiviso e una configurazione dell'architettura che viene mantenuta in un archivio di configurazione distribuito (DCS). Le opzioni per implementare un DCS includono: etcd, Consul, Apache ZooKeeper, o Kubernetes. Il seguente diagramma mostra i componenti principali di un cluster Patroni.

Un cluster Patroni prevede l'interazione tra i nodi PostgreSQL, il DCS e gli agenti Patroni.

Figura 1. Diagramma dei componenti principali di un cluster Patroni.

Nella figura 1, i bilanciatori del carico si trovano davanti ai nodi PostgreSQL e gli agenti DCS e Patroni operano sui nodi PostgreSQL.

Patroni esegue un processo agente su ogni nodo PostgreSQL. Il processo dell'agente gestisce la configurazione del processo PostgreSQL e del nodo di dati. L'agente Patroni coordina gli altri nodi tramite il DCS. Il processo dell'agente Patroni espone anche un'API REST che puoi interrogare per determinare l'integrità e la configurazione del servizio PostgreSQL per ogni nodo.

Per affermare il proprio ruolo di membro del cluster, il nodo primario aggiorna regolarmente la chiave leader nel DCS. La chiave leader include una durata (TTL). Se il TTL scade senza un aggiornamento, la chiave leader viene rimossa dal DCS e inizia la selezione del leader per scegliere un nuovo primario dal pool di candidati.

Il seguente diagramma mostra un cluster integro in cui il nodo A aggiorna correttamente il blocco leader.

Un leader del cluster integro aggiorna il blocco del leader mentre i candidati leader osservano.

Figura 2. Diagramma di un cluster integro.

La Figura 2 mostra un cluster integro: i nodi B e C osservano mentre il nodo A aggiorna correttamente la chiave leader.

Rilevamento errori

L'agente Patroni segnala continuamente il suo stato aggiornando la chiave nel DCS. Allo stesso tempo, l'agente convalida l'integrità di PostgreSQL; se l'agente rileva un problema, esegue l'isolamento automatico del nodo arrestandosi o declassa il nodo a replica. Come mostrato nel seguente diagramma, se il nodo compromesso è il nodo primario, la relativa chiave leader nel DCS scade e viene eseguita una nuova elezione del leader.

Un cluster compromesso elegge un nuovo leader dopo la scadenza della chiave del leader esistente.

Figura 3. Diagramma di un cluster compromesso.

La Figura 3 mostra un cluster compromesso: un nodo primario inattivo non ha aggiornato di recente la chiave leader nel DCS e le repliche non leader ricevono una notifica che indica che la chiave leader è scaduta.

Sugli host Linux, Patroni esegue anche un watchdog a livello di sistema operativo sui nodi primari. Questo watchdog è in ascolto dei messaggi keep-alive del processo dell'agente Patroni. Se il processo non risponde e il segnale di mantenimento in vita non viene inviato, il watchdog riavvia l'host. Il watchdog aiuta a prevenire una condizione di split brain in cui il nodo PostgreSQL continua a fungere da primario, ma la chiave leader nel DCS è scaduta a causa di un errore dell'agente ed è stato scelto un altro primario (leader).

Processo di failover

Se il blocco del leader scade in DCS, i nodi di replica candidati iniziano una selezione del leader. Quando una replica rileva un blocco leader mancante, controlla la sua posizione di replica rispetto alle altre repliche. Ogni replica utilizza l'API REST per ottenere le posizioni dei log WAL degli altri nodi di replica, come mostrato nel seguente diagramma.

Durante la procedura di failover di Patroni, le repliche controllano la loro posizione nel log WAL.

Immagine 4. Diagramma del processo di failover di Patroni.

La figura 4 mostra le query sulla posizione del log WAL e i rispettivi risultati dei nodi di replica attivi. Il nodo A non è disponibile e i nodi integri B e C restituiscono la stessa posizione WAL.

Il nodo (o i nodi, se si trovano nella stessa posizione) più aggiornato tenta contemporaneamente di acquisire il blocco leader nel DCS. Tuttavia, solo un nodo può creare la chiave leader nel DCS. Il primo nodo a creare correttamente la chiave leader è il vincitore della corsa al leader, come mostrato nel seguente diagramma. In alternativa, puoi designare i candidati di failover preferiti impostando il tag failover_priority nei file di configurazione.

Un nodo crea una chiave leader nel DCS e diventa il nuovo nodo primario.

Figura 5. Diagramma della classifica.

La figura 5 mostra una competizione per la leadership: due candidati leader tentano di ottenere il blocco del leader, ma solo uno dei due nodi, il nodo C, imposta correttamente la chiave del leader e vince la competizione.

Dopo aver vinto l'elezione del leader, la replica viene promossa a nuova istanza principale. A partire dal momento in cui la replica si promuove, la nuova istanza principale aggiorna la chiave leader nel DCS per mantenere il blocco leader e gli altri nodi fungono da repliche.

Patroni fornisce anche lo strumento di controllo patronictl che ti consente di eseguire i cambi di ruolo per testare la procedura di failover dei nodi. Questo strumento aiuta gli operatori a testare le configurazioni HA in produzione.

Routing delle query

Il processo dell'agente Patroni eseguito su ogni nodo espone endpoint API REST che rivelano il ruolo attuale del nodo: principale o replica.

Endpoint REST	Codice restituito HTTP se primario	Codice restituito HTTP se la replica
`/primary`	`200`	`503`
`/replica`	`503`	`200`

Poiché i controlli di integrità pertinenti modificano le proprie risposte se un determinato nodo cambia ruolo, un controllo di integrità del bilanciatore del carico può utilizzare questi endpoint per informare il routing del traffico dei nodi primari e di replica. Il progetto Patroni fornisce configurazioni modello per un bilanciatore del carico come HAProxy . Il bilanciatore del carico di rete passthrough interno può utilizzare questi stessi controlli di integrità per fornire funzionalità simili.

Procedura di riserva

Se si verifica un errore del nodo, il cluster rimane in stato di funzionamento ridotto. La procedura di failback di Patroni consente di ripristinare un cluster ad alta disponibilità in uno stato integro dopo un failover. Il processo di fallback gestisce il ripristino dello stato originale del cluster inizializzando automaticamente il nodo interessato come replica del cluster.

Ad esempio, un nodo potrebbe riavviarsi a causa di un errore nel sistema operativo o nell'infrastruttura sottostante. Se il nodo è il nodo principale e impiega più tempo del TTL della chiave leader per riavviarsi, viene attivata una selezione del leader e viene selezionato e promosso un nuovo nodo principale. Quando viene avviato il processo Patroni primario obsoleto, rileva di non avere il blocco leader, si declassa automaticamente a replica e si unisce al cluster in questa veste.

Se si verifica un errore del nodo non recuperabile, ad esempio un errore di zona improbabile, devi avviare un nuovo nodo. Un operatore di database può avviare manualmente un nuovo nodo oppure puoi utilizzare un gruppo di istanze gestite (MIG) stateful a livello di regione con un numero minimo di nodi per automatizzare il processo. Dopo la creazione del nuovo nodo, Patroni rileva che fa parte di un cluster esistente e lo inizializza automaticamente come replica.

HA utilizzando l'estensione e il servizio pg_auto_failover

pg_auto_failover è un'estensione PostgreSQL open source (licenza PostgreSQL) in fase di sviluppo attivo. pg_auto_failover configura un'architettura HA estendendo le funzionalità PostgreSQL esistenti. pg_auto_failover non ha dipendenze diverse da PostgreSQL.

Per utilizzare l'estensione pg_auto_failover con un'architettura HA, devi avere almeno tre nodi, ognuno dei quali esegue PostgreSQL con l'estensione abilitata. Uno qualsiasi dei nodi può non funzionare senza influire sull'uptime del gruppo di database. Una raccolta di nodi gestiti da pg_auto_failover è chiamata formazione. Il seguente diagramma mostra un'architettura pg_auto_failover.

Un'architettura pg_auto_failover contiene una formazione di nodi.

Immagine 6. Diagramma di un'architettura pg_auto_failover.

La Figura 6 mostra un'architettura pg_auto_failover composta da due componenti principali: il servizio Monitor e l'agente Keeper. Sia Keeper che Monitor sono contenuti nell'estensione pg_auto_failover.

Monitorare il servizio

Il servizio di monitoraggio pg_auto_failover è implementato come estensione PostgreSQL; quando il servizio crea un nodo di monitoraggio, avvia un'istanza PostgreSQL con l'estensione pg_auto_failover abilitata. Il monitor mantiene lo stato globale per la formazione, ottiene lo stato del controllo di integrità dai nodi di dati PostgreSQL membri e orchestra il gruppo utilizzando le regole stabilite da una macchina a stati finiti (FSM). In base alle regole FSM per le transizioni di stato, il monitor comunica istruzioni ai nodi del gruppo per azioni come la promozione, il declassamento e le modifiche alla configurazione.

Agente di Keeper

Su ogni nodo di dati pg_auto_failover, l'estensione avvia un processo dell'agente Keeper. Questo processo Keeper osserva e gestisce il servizio PostgreSQL. Il Keeper invia aggiornamenti di stato al nodo Monitor e riceve ed esegue le azioni che Monitor invia in risposta.

Per impostazione predefinita, pg_auto_failover configura tutti i nodi di dati secondari del gruppo come repliche sincronizzate. Il numero di repliche sincrone richieste per un commit si basa sulla configurazione number_sync_standby impostata sul monitor.