Una delle caratteristiche interessanti di PostgreSQL dalla versione 9.4 è la capacità di controllare la rimozione dei file WAL utilizzando gli slot di replica. Il lato oscuro è che gli slot di replica possono causare il riempimento dei dischi con il vecchio WAL, uccidendo il server di produzione principale. In questo articolo spiego gli slot di replica di PostgreSQL e come una nuova funzionalità in PostgreSQL 13 aiuta a prevenire questo problema.

Produzione WAL

Come sapete, WAL viene prodotto per le modifiche al database in un server primario:inserimenti, aggiornamenti, ecc . Un database più attivo produrrà più WAL:in un server molto attivo, possono essere prodotti molti gigabyte di WAL ogni minuto. WAL viene scritto su file con nomi in una sequenza numerica crescente e i file hanno sempre la stessa dimensione (16 MB è l'impostazione predefinita e tipica). Una volta che i dati in un file non sono più necessari, quel file può essere riciclato , il che significa rinominarlo in una posizione con un numero più alto nella sequenza in modo che possa essere riempito con nuovi dati in un secondo momento.

(Ci sono situazioni speciali come un aumento dell'attività che porta alla creazione di file aggiuntivi; quando in seguito l'aumento si attenua, quei file extra vengono rimossi anziché riciclati.)

Poiché tutta l'attività di scrittura del database produce WAL, è fondamentale che lo spazio su disco sia disponibile. Quando il disco di archiviazione WAL è pieno, il server non sarà in grado di elaborare nuove transazioni e potrebbe bloccarsi, o peggio:potrebbe cadere completamente. Quindi questa è una situazione da evitare con tutti i mezzi possibili.

Slot di replica

La replica in PostgreSQL funziona elaborando i file WAL. Affinché ciò funzioni, tutti i file WAL devono essere disponibili transitoriamente fino a quando non vengono elaborati. Pertanto è necessario un meccanismo per dire alla gestione principale di WAL di non riciclare o rimuovere file.

Inserisci gli slot di replica. Le slot sono un meccanismo che indica che questo il backup che stiamo facendo richiederà quello WAL e, per favore, non eliminarlo ancora; o questo replica non ha ancora elaborato quello WAL, quindi puoi lasciarlo in pace per un po'.

Di per sé, gli slot di replica occupano pochissimo spazio su disco. Memorizzano solo una piccola parte di metadati, incluso un puntatore a una posizione in WAL. Ma i dati WAL che protegge sono un'altra questione:in un server altamente attivo, possono essere misurati in gigabyte o peggio.

Consumo WAL

Fornire dati a una replica fisica significa copiare i dati WAL dal suo server primario. Allo stesso modo, una replica logica deve leggere i dati WAL (e trasmettere una versione interpretata alla replica). La posizione WAL letta è ciò di cui lo slot tiene traccia. Una volta che la replica ha protetto in qualche modo i dati WAL, lo slot può essere avanzato; questo dice alla gestione WAL nel primario che il file WAL è quindi disponibile per la rimozione. Ciò accade continuamente quando la replica è attiva, in modo che WAL nel server primario utilizzi la stessa quantità di spazio su disco o forse solo un po' di più. Anche il doppio o dieci volte tanto potrebbe essere accettabile, a seconda delle condizioni.

Il problema è che se una replica muore completamente e non si ripristina per un lungo periodo di tempo; oppure la replica viene distrutta e il DBA dimentica di rimuovere lo slot di replica; oppure lo slot è un avanzo dimenticato di qualche esperimento; o anche la replica viene alimentata su un collegamento di rete lento, il WAL riservato crescerà senza limiti. E quella diventa una bomba ad orologeria.

Limitazione delle dimensioni degli slot

Per combattere questo problema, Kyotaro Horiguchi ha lavorato da febbraio 2017 in una patch PostgreSQL per limitare la dimensione del WAL riservato da uno slot. Dopo un lungo processo di revisione e rielaborazione, l'ho integrato per PostgreSQL 13, migliorando la gestione delle farm PostgreSQL ad alta disponibilità.

Il principio principale è che è meglio uccidere una replica (rendendo in qualche modo non valido il suo slot; ne parleremo più avanti) piuttosto che uccidere il server primario che alimenta quella replica e portare con sé tutta la produzione.

Il modo in cui funziona è piuttosto semplice:imposta max_slot_wal_keep_size (documentazione) in postgresql.conf alla quantità massima di spazio su disco di WAL che gli slot di replica possono riservare. Se uno slot raggiunge quel punto e si verifica un checkpoint, quello slot verrà contrassegnato come non valido e alcuni file WAL potrebbero essere eliminati. Se lo slot era in uso attivo da un walsender processo, quel processo verrà segnalato in modo che termini. Se il walsender si riavvia, scoprirà che i file WAL necessari non saranno più lì. La replica che utilizza quello slot dovrà essere riclonata.

Se max_slot_wal_keep_size è zero, che è il valore predefinito, quindi non c'è limite. Non lo consiglio, perché porta a errori quando gli slot riempiono il disco.

Monitoraggio della salute degli slot

Sono incluse anche alcune funzioni di monitoraggio. Sono rilevanti due colonne in pg_replication_slots. Il più critico è wal_status . Se quella colonna è reserved , lo slot punta ai dati all'interno di max_wal_size; se è extended quindi ha superato max_wal_size , ma è comunque protetto da wal_keep_size o max_slot_wal_keep_size (incluso quando max_slot_wal_keep_size è zero). Entrambi gli stati sono buoni e normali. Tuttavia, quando uno slot supera il limite, diventa prima unreserved , il che significa che è in pericolo imminente, ma può comunque riprendersi se è abbastanza veloce. Infine, lo stato diventa lost quando i file WAL sono stati rimossi e non è possibile alcun ripristino.

L'altra colonna è safe_wal_size :mostra il numero di byte di WAL che possono essere scritti prima che questo slot rischi di rimuovere i file WAL. Ti consigliamo di tenere d'occhio questa colonna nel tuo sistema di monitoraggio e di avvisare quando si abbassa. Zero o negativo significa che la tua replica sarà morta non appena si verifica un checkpoint:

SELECT slot_name, active, wal_status, safe_wal_size
  FROM pg_catalog.pg_replication_slots;

Riteniamo che questa nuova funzionalità renda la manutenzione delle repliche più semplice e robusta; speriamo di non vedere altri disastri con la produzione in calo a causa di questi problemi.

(Una nota:safe_wal_size è stato introdotto in 13beta3, quindi assicurati di consultare la documentazione aggiornata, altrimenti vedrai min_safe_lsn invece. Ignoralo.)

Grazie

Un ringraziamento speciale a Kyotaro Horiguchi per aver lavorato alla risoluzione di questo problema. Diversi revisori hanno approfondito questo argomento, tra i quali vorrei ringraziare in particolare Masahiko Sawada, Fujii Masao, Jehan-Guillaume de Rorthais e Amit Kapila (senza un ordine particolare).