Barman 1.4.0: le modifiche più importanti

L’ultima release aggiunge una nuova modalità di backup: il backup incrementale, che permette il riuso dei file non modificati fra un backup periodico e l’altro, riducendo drasticamente i tempi di esecuzione, la banda utilizzata e lo spazio occupato su disco.
Altra nuova funzionalità introdotta con la 1.4.0 è l’integrazione di Barman con la vista pg_stat_archiver, disponibile dalla versione 9.4 di PostgreSQL. Questa vista permette di raccogliere informazioni sulle performance del processo di archiviazione dei WAL e di monitorarne lo stato.
La gestione dei WAL file è migliorata. Il calcolo delle statistiche di archiviazione è stato snellito e ottimizzato. È stata potenziata la logica relativa alla rimozione dei WAL obsoleti, andando a effettuare azioni diverse nel caso di backup esclusivi o concorrenti.
I messaggi prodotti in caso di errore sono stati migliorati, rendendoli, dove possibile, più chiari e leggibili.
Abbiamo inoltre investito nella robustezza del codice: con Barman 1.4.0 disponiamo di circa 200 test di unità che vengono eseguiti ad ogni patch.

Backup Incrementale

Approfondiamo adesso la principale novità di questa release: il backup incrementale.

Definizione e teoria alla base

Per comprendere la logica su cui si basa il backup incrementale, prendiamo in considerazione due backup completi e consecutivi. Nell’intervallo di tempo che intercorre fra il completamento del primo backup e il completamento del backup successivo, non tutti i file contenuti all’interno della directory PGDATA vengono modificati. Alcuni file del backup più vecchio e del più recente, sono identici e perciò risultano ridondanti, richiedendo tempo e banda per essere trasferiti via rete e occupando spazio sul disco una volta terminata la copia. Se compariamo i file che compongono il backup più vecchio con i file che stiamo per andare a copiare dal server remoto, è possibile distinguere l’insieme di file che ha subito modifiche da quello che invece è rimasto invariato.
Con il backup incrementale diventa quindi possibile eliminarne la ridondanza, andando a copiare solamente i file modificati.

Implementazione e vantaggi tangibili

Abbiamo sviluppato questa funzionalità ponendoci tre obiettivi:

• riduzione del tempo di esecuzione di un backup;
• riduzione dell’utilizzo di banda;
• riduzione dello spazio occupato eliminando le ridondanze (deduplicazione).

Per ottenerli abbiamo sfruttato la capacità di Rsync di comparare una lista di file ricevuta da un server remoto, con il contenuto di una directory locale, identificando quali siano stati modificati o meno. Abbiamo aggiunto quindi una nuova opzione di configurazione per server/globale chiamata reuse_backup. Questa opzione identifica il tipo di backup che verrà effettuato.
Vediamo i tre possibili valori di reuse_backup e i loro effetti:

• off: valore di default, backup classico;
• copy: identifica sul server remoto l’insieme di file modificati, utilizzando l’ultimo backup eseguito come base. Solamente i file che risultano modificati vengono trasferiti via rete, diminuendo i tempi di esecuzione di un backup e risparmiando banda. Al termine del trasferimento dal backup usato come base, vengono copiati i file non modificati, ottenendo così un backup completo;
• link: identifica i file modificati e ne esegue la copia, esattamente come l’opzione copy. Al termine del trasferimento, il riuso dei file identificati come non modificati non viene ottenuto copiandoli, ma utilizzando degli hard link. In questo modo viene ottimizzato lo spazio sul disco occupato dal backup ed effettivamente si eliminano le ridondanze (deduplicazione).

È inoltre possibile utilizzare la seguente opzione --reuse-backup [{copy, link, off}] da linea di comando per modificare il comportamento di default per un singolo backup.
Per esempio:

$> barman backup --reuse-backup link main

forzerà il riuso del backup utilizzando gli hard link indipendentemente dal valore impostato all’interno del file di configurazione.
Utilizzerò adesso come “caso di studio” Navionics, uno dei nostri clienti e sponsor di questa release che, come vedremo, trae grossi vantaggi dall’utilizzo del backup incrementale. Navionics possiede database di notevoli dimensioni (uno dei più grandi arriva a circa 13 Terabyte). Prima dell’introduzione del backup incrementale, tenendo conto delle caratteristiche del server e della rete:

• sarebbero state necessarie circa 52 ore per completare un backup;
• sarebbero stati effettivamente copiati 13 TiB di dati tramite la rete;
• sarebbero stati occupati effettivamente 13 TiB sul disco.

Con Barman 1.4.0, utilizzando reuse_backup=link e facendo barman show-backup di un backup appena terminato, Navionics ottiene:

Base backup information:
  Disk usage           : 13.2 TiB (13.2 TiB with WALs)
  Incremental size     : 5.0 TiB (-62.01%)

Il tempo di esecuzione del backup è sceso drasticamente da 52 ore a 17 ore circa. I vantaggi sono quindi evidenti:

• il tempo di esecuzione diminuisce del 68% circa;
• sono stati copiati via rete solo 5.0 TiB di dati al posto di 13 TiB (-62%);
  
• lo spazio occupato sul disco è 5.0 TiB al posto di 13 TiB (-62%).

pg_stat_archiver: integrazione in Barman 1.4.0

Fra le novità introdotte da PostgreSQL 9.4 abbiamo la vista pg_stat_archiver che fornisce dati utili riguardanti lo stato di funzionamento del processo di archiviazione dei WAL. Grazie a queste statistiche è possibile inoltre fare previsioni sullo spazio che un nuovo backup andrà a occupare. Gli utenti di Barman 1.4.0 e PostgreSQL 9.4 potranno notare la comparsa di alcuni nuovi campi all’interno dell’output dei seguenti comandi:

• barman check:
  • il campo booleano is_archiving che indica lo stato del processo di archiviazione.
• barman status:
  • last_archived_time riporta l’ora di archiviazione dell’ultimo WAL file;
  • failed_count il numero di tentativi di archiviazione di WAL falliti;
  • server_archived_wals_per_hour il tasso di archiviazione di WAL/ora;
• barman show-server aggiunge all’insieme delle statistiche del server tutti i campi che compongono la vista pg_stat_archiver.

Conclusioni

Il backup incrementale, funzionalità principale di questa release, è sicuramente uno strumento di grande utilità per tutti, permettendo di salvare tempo e spazio anche su database di dimensioni modeste. Diventa invece quasi indispensabile per tutti coloro che devono amministrare database di grosse dimensioni (VLDB) o che contengono un grosso numero di tabelle in sola lettura, fornendo un notevole incremento di prestazioni in termini di spazio occupato, tempo e banda.
Aggiungendo l’integrazione con pg_stat_archiver su PostgreSQL 9.4 migliora la capacità di monitorare lo stato dei server e quindi la salute e la robustezza di tutte quelle infrastrutture che scelgono Barman come soluzione di disaster recovery di database PostgreSQL.

La novità principale di Barman 1.4.0 è il backup incrementale a livello di file, cioè un backup periodico completo che salva solo le modifiche dei dati effettuate dall’ultimo backup.

Il “data deduplication ratio” potrà facilmente raggiungere il 50-70% per ogni backup completo, portando riduzioni significative sia sui tempi di backup che sull’utilizzo dello spazio su disco.

Gli utenti di PostgreSQL 9.4 potranno inoltre beneficiare dell’integrazione di Barman con la vista pg_stat_archiver: qualsiasi problema di archiviazione continua sarà individuato immediatamente da Barman.

La gestione dei file WAL è stata migliorata ottimizzando il calcolo delle statistiche WAL, inoltre sono stati corretti alcuni bug minori.

Backup incrementale

Con backup incrementale si intende un backup periodico completo che salva solo le modifiche dei dati effettuate dall’ultimo backup.

I principali obiettivi del backup incrementale in Barman sono:

• ridurre il tempo necessario per il processo di backup;
• ridurre lo spazio su disco occupato dai diversi backup periodici (deduplicazione dei dati).

Questa caratteristica si basa molto su rysnc e hard link che devono essere pertanto supportati sia dal sistema operativo che dai file system in cui risiedono i dati di backup. Due backup periodici di base condivideranno i file che non sono stati modificati, con un risparmio rilevante dell’utilizzo del disco.

Per una lista completa delle modifiche, si consiglia la lettura del comunicato ufficiale in lingua inglese.

Cos’è Barman

Barman (Backup And Recovery Manager per PostgreSQL) è un software open-source scritto in Python. Permette di eseguire backup remoti su più server in ambienti business critical e di supportare gli amministratori di database durante la fase di recovery. Le funzionalità più apprezzate di Barman sono: cataloghi di backup, backup incrementale, retention policy, backup remoto e recovery, archiviazione e compressione dei file WAL e backup.

Barman è progettato, implementato e mantenuto da 2ndQuadrant Italia e distribuito secondo licenza GNU GPL 3.

Grazie al linguaggio SQL è possibile, in ogni istante, controllare lo stato di funzionamento del processo di archiviazione dei log transazionali (WAL), componente cruciale di un sistema di disaster recovery con PostgreSQL.

Introduzione e motivazioni

Questa vista nasce dall’esigenza, emersa in questi anni, di utilizzare Barman come soluzione di disaster recovery di database PostgreSQL in ambienti in continuità operativa.

In particolare, alcune delle necessità e delle domande ricorrenti che DBA, sistemisti, CTO e CIO legittimamente ci chiedono, sono:

• Di quanto spazio disco avrò bisogno?
• Come posso tenere sotto controllo il processo di backup e di archiviazione continua?

Il punto di partenza, come è naturale che sia, è un requisito di business, che si traduce nel concetto di retention policy. Solitamente, un’azienda definisce un piano di disaster recovery all’interno di un piano di continuità operativa, dove è stabilito chiaramente il periodo di conservazione dei dati di backup. Negli stessi documenti troviamo sia il recovery point objective (RPO) che il recovery time objective (RTO), le due metriche fondamentali che misurano la quantità di dati che un’azienda può tollerare di perdere e il tempo massimo di ripristino in seguito a un disastro.
Il monitoraggio e lo studio del comportamento passato di un database sono elementi fondamentali per dimensionare, a livello di storage, una soluzione di backup.

Ad esempio, un’azienda può decidere di conservare i dati di un database PostgreSQL per un mese, in modo da ricostruire la situazione del database in maniera consistente in qualsiasi istante a partire dal primo backup a disposizione, fino all’ultimo file WAL correttamente archiviato (tramite il robustissimo meccanismo di Point-In-Time-Recovery di PostgreSQL).

La dimensione necessaria è data non solo dal numero di backup completi periodici (ad esempio uno a settimana), ma anche dal numero di file WAL archiviati, ognuno contenente le transazioni correttamente eseguite sul database in modo differenziale.

Una delle metriche necessarie è pertanto il numero di file WAL archiviati al secondo, tramite le quali è possibile stimare il numero di WAL prodotti in una settimana ed essere in grado di fare previsioni di utilizzo del disco.

A meno di non usare strumenti di campionamento e di trending (e.g. Munin), di esaminare i timestamp dei file WAL sfruttando un wal_keep_segments alto, oppure delegare questa informazione allo script personalizzato di archiviazione invocato da archive_command, fino alla versione 9.4, PostgreSQL non era in grado di fornire statistiche sul numero di file WAL archiviati, l’orario di archiviazione, l’ultimo WAL archiviato e così via. Tantomeno poteva riportare informazioni in merito al numero di file WAL per i quali l’archiviazione era fallita e l’orario di ultimo fallimento.

Sono questi i motivi per cui un anno fa ho deciso di scrivere una piccola patch per Postgres, patch che è stata poi inserita nel core all’interno della versione 9.4.

Questa patch aggiunge una statistica real-time al catalogo di PostgreSQL chiamata pg_stat_archiver.

Overview della statistica

La vista pg_stat_archiver di PostgreSQL 9.4 rende disponibile a tutti coloro che utilizzano Barman o il backup continuo classico tramite WAL file shipping, i seguenti campi:

• archived_count: numero di file WAL archiviati con successo
• last_archived_wal: nome dell’ultimo file WAL archiviato con successo
• last_archived_time: orario dell’ultima archiviazione di WAL eseguita con successo
• failed_count: numero di tentativi falliti di archiviazione di WAL
• last_failed_wal: nome dell’ultimo file WAL con tentativo di archiviazione fallito
• last_failed_time: orario dell’ultima archiviazione di WAL fallita
• stats_reset: orario di reset delle statistiche

Ecco un esempio ricavato da un database server locale, poco utilizzato:

postgres=# SELECT * FROM pg_stat_archiver;
-[ RECORD 1 ]------+-----------------------------------------
archived_count     | 17
last_archived_wal  | 00000001000000000000000B.00000028.backup
last_archived_time | 2014-12-23 08:40:17.858291+01
failed_count       | 13
last_failed_wal    | 000000010000000000000001
last_failed_time   | 2014-12-04 13:09:07.348307+01
stats_reset        | 2014-12-03 16:52:21.755025+01

Essenzialmente, una volta attivata l’archiviazione continua con archive_mode, PostgreSQL si fa responsabile che, per ogni file WAL prodotto, il comando archive_command venga eseguito con successo, riprovando all’infinito (spazio su disco permettendo) in caso di fallimento.

A differenza delle versioni precedenti, PostgreSQL 9.4 è in grado adesso di raccogliere alcune informazioni sui due principali eventi che possono verificarsi con l’archiviazione: successo e fallimento. In particolare, per entrambe le operazioni vengono resi disponibili:

• Conteggio (a partire dall’inizializzazione del cluster oppure dall’ultimo reset delle statistiche);
• WAL di riferimento dell’ultima operazione;
• Orario dell’ultima operazione.

Tra l’altro, è possibile azzerare le statistiche di archiviazione con l’istruzione:

-- Richiede privilegi superuser
SELECT pg_stat_reset_shared('archiver');

Integrazione con Barman

A partire dalla versione 1.4, Barman sfrutterà la vista pg_stat_archiver per i database PostgreSQL 9.4 in modo automatico e trasparente, riportando le informazioni di archiviazione nei classici comandi Barman di visualizzazione di un server, come status e show-server.

Inoltre, sfruttando la potenza del linguaggio SQL, è stata migliorata l’affidabilità del comando check, adesso in grado di rilevare un problema di archiviazione direttamente dalla fonte.

Esaminiamo velocemente la query introdotta in Barman:

SELECT *,
    current_setting('archive_mode')::BOOLEAN
        AND (last_failed_wal IS NULL
            OR last_failed_wal <= last_archived_wal)
        AS is_archiving,
    CAST (archived_count AS NUMERIC)
        / EXTRACT (EPOCH FROM age(now(), stats_reset))
        AS current_archived_wals_per_second
FROM pg_stat_archiver

Oltre a recuperare tutte le colonne della vista pg_stat_archiver, la query calcola al volo due campi, direttamente dalla fonte:

• is_archiving: il processo di archiviazione dei WAL è in corso oppure no?
• current_archived_wals_per_second: frequenza di WAL archiviati per secondo

Il campo is_archiving deve essere sempre TRUE, in quanto il processo di archiviazione è necessario per Barman. Pertanto, archive_mode deve essere attivo e il valore dell’ultimo WAL deve essere non definito (NULL) oppure non successivo all’ultimo WAL correttamente archiviato. Questo controllo è adesso parte integrante del comando barman check su server Postgres 9.4 (e future versioni).

Il secondo campo invece restituisce una statistica molto interessante sul workload prodotto dai server Postgres e permette pertanto di stimare lo spazio su disco richiesto per memorizzare (anche in modo compresso) giorni, settimane e mesi di file WAL (rispondendo così a una delle importanti domande iniziali).

Come controllare lo stato di funzionamento dell’archiviazione

Grazie a pg_stat_archiver, controllare lo stato di funzionamento dell’archiviazione continua dei WAL si riduce all’esecuzione di una query SQL.

È possibile impiegare la query esposta in precedenza, già utilizzata in Barman, per verificare che l’archiviazione stia procedendo con successo, integrandola nelle sonde o plugin del sistema di alerting utilizzato in azienda.

Coloro che utilizzano Barman con server PostgreSQL 9.4 e hanno già integrato barman check all’interno Nagios o Icinga, beneficeranno in modo trasparente di questa funzionalità.

Conclusioni

La vista pg_stat_archiver, nella sua semplicità, rappresenta uno strumento molto importante per coloro che considerano la disaster recovery una componente cruciale, e non periferica, di un sistema PostgreSQL in business continuity.

Anche se PostgreSQL permette di eseguire backup utilizzando la replica in streaming, l’archiviazione continua dei file WAL tramite shipping rappresenta comunque un metodo di fallback sicuro e affidabile (e comunque l’unico finora supportato da Barman). Pertanto, il corretto monitoraggio di questa componente aumenta sensibilmente la robustezza di tutta la soluzione di database Postgres.

Infine, poter disporre di statistiche circa il numero di WAL archiviati (e pertanto prodotti) da un server PostgreSQL in un periodo di riferimento, permette di conoscere con una semplice query il workload transazionale e poter fare previsioni sull’occupazione a livello di disco di una soluzione di backup.

Nella puntata precedente, abbiamo introdotto la funzionalità di replica logica aggiunta a PostgreSQL 9.4. Continuiamo a nuotare nel mare di novità che la versione 9.4 porta nel campo Operation, con l’obiettivo di migliorare la gestione di database PostgreSQL per amministratori di sistema e DBA.

pg_prewarm

pg_prewarm è una nuova estensione per risolvere il problema dei rallentamenti post riavvio. In seguito a un riavvio di PostgreSQL, infatti, i buffer sono cancellati e Postgres non è più in grado di ritrovare subito in RAM i dati richiesti. Con pg_prewarm è possibile caricare in memoria una tabella importante immediatamente dopo il riavvio con un semplice

SELECT pg_prewarm('my_table');

In questo modo non sarà più necessario avere un database a regime per avere i dati in cache.

Gestione dei tablespace

Due piccole novità sono state introdotte per semplificare l’uso dei tablespace. La prima è l’introduzione del comando ALTER TABLESPACE … MOVE, che permette di spostare tabelle, indici e viste materializzate da un tablespace a un altro. La seconda è la sintassi CREATE TABLESPACE … WITH … options con cui diventa possibile impostare opzioni del tablespace direttamente in fase di creazione, risparmiando un secondo ALTER TABLESPACE. I due parametri possibili al momento sono seq_page_cost e random_page_cost, che possono essere utili al planner per comprendere quali dischi sono più veloci di altri.

CREATE TABLESPACE new_tblspc LOCATION 'my_dir' WITH random_page_cost = 1;
ALTER TABLESPACE old_tblspc MOVE TABLES TO new_tblspc;

Monitoraggio dell’archiviazione dei WAL

Nel corso del nostro lavoro su Barman in 2ndQuadrant, più volte ci siamo trovati a stimare la produzione di WAL di un server. Per questo, il nostro Gabriele Bartolini ha sviluppato questa patch. Adesso è possibile avere a disposizione una tabella di statistiche sull’attività dell’archiver che mostra il numero di WAL archiviati nel tempo (e, eventualmente, di archiviazioni fallite).

SELECT * FROM pg_stat_archiver;
-[ RECORD 1 ]------+------------------------------
 archived_count     | 4
 last_archived_wal  | 00000001000000000000000B
 last_archived_time | 2014-10-07 08:58:02.258657+00
 failed_count       | 0
 last_failed_wal    |
 last_failed_time   |
 stats_reset        | 2014-10-07 08:51:29.852523+00

Standby ritardati nel tempo

Se uno standby è uno strumento utile nel caso di crash del master, è totalmente inutile nel caso di un errore umano. Una “DROP TABLE” errata da parte dell’amministratore e diventa immediatamente necessaria una Point In Time Recovery. La possibilità di avere un server in replica che applichi i cambiamenti con un certo ritardo concede invece un intervallo di tempo per fermare la replica, evitando che l’errore si propaghi.

Per impostare ad esempio uno standby in ritardo di almeno un’ora, basta impostare nel recovery.conf:

min_recovery_apply_delay = 1h

Modifica della configurazione

Un altro nuovo comando introdotto nella 9.4 per rendere più comodo lavorare con PostgreSQL è ALTER SYSTEM. Adesso è diventato possibile cambiare il file postgresql.conf da dentro una connessione SQL. Con le sole eccezioni dei parametri impostabili in fase di compilazione e della PGDATA, gli altri possono essere modificati come dell’esempio successivo:

ALTER SYSTEM SET wal_level = hot_standby;

I nuovi valori saranno scritti nel file postgresql.auto.conf. Resta necessario eseguire un reload o un riavvio per i parametri che lo richiedono.

Performance dei WAL

Per quanto riguarda i WAL, non ci sono comandi nuovi, ma miglioramenti delle prestazioni. È stata ridotta la lock contention per le operazioni di insert nei WAL. Inoltre, è stata diminuita la dimensione dei WAL record generati dalle UPDATE. In questo modo sarà possibile effettuare più scritture impiegando minore I/O.

Conclusioni

Per noi amministratori di sistemi Linux e DBA, PostgreSQL 9.4 migliora ulteriormente la gestione ordinaria di database in continuità operativa. Inoltre, pone le basi per aprire nuovi orizzonti in ambito architetturale, fra cui la replica multi-master. Grazie alla replica logica, infatti, vedremo sicuramente gli strumenti di replica basati su trigger (come Londiste, Slony, Bucardo) aggiungere il supporto alla decodifica degli eventi direttamente da replication slot logici, rendendo molto più snella la gestione della replica. Se siete interessati, potete seguire il nostro blog con l’articolo di Giuseppe sulle novità per sviluppatori. A presto!