Questa minor release consolida il ruolo centrale di Barman nelle installazioni di business continuity di database PostgreSQL e ora permette agli utenti di implementare i comandi per il restore remoto in parallelo su server in standby e durante la recovery.

Inoltre, attraverso il nuovo comando ‘replication-status’, Barman diventa uno strumento molto pratico per il monitoraggio della replica in streaming di ogni server che gestisce.

Sono stati implementati anche altri importanti miglioramenti e sono state effettuate alcune correzioni di bug minori. Per maggiori informazioni, leggi l’annuncio completo oltre all’articolo in inglese scritto dal nostro Gabriele ‘Waiting for Barman 1.6.1‘.

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.

Finalmente ci siamo: l’ottava edizione del PGDay italiano è al via!
La principale conferenza annuale a livello italiano sul database open source PostgreSQL si terrà a Prato questo venerdì, 7 novembre 2014, presso il Polo Universitario Città di Prato (PIN), sede distaccata dell’Università degli Studi di Firenze.

L’evento è organizzato dall’associazione no-profit Italian PostgreSQL Users Group (ITPUG) con l’obiettivo di promuovere il software libero e open source, ed in particolare l’adozione di PostgreSQL (o semplicemente Postgres) come soluzione per la gestione di database nelle aziende, nella pubblica amministrazione e nelle scuole.

La registrazione al PGDay italiano 2014 ha un costo complessivo di 90 euro (comprendente coffee break e pranzo). Per gli studenti, la quota di iscrizione è fissata a 30 euro.

In occasione della conferenza, sono previsti tre eventi sociali:

• pg_birra_pre, giovedì 6 novembre, ore 18: Interlogica, uno dei partner dell’evento, offrirà alcune consumazioni – Presso il pub Camelot 3.0 in via Santo Stefano 20-22, accanto al Duomo di Prato
• pg_cena, giovedì 6 novembre, ore 20 : Menu PGDay, acquistabile via Internet: 18 € (primo, secondo, contorni, una birra chiara o un bicchiere di vino, caffè) – Presso il pub Camelot 3.0 in via Santo Stefano 20-22, accanto al Duomo di Prato
  
• pg_birra_post, venerdì 7 novembre, ore 18

Per coloro che venerdì 7 novembre intendono continuare a festeggiare il PGDay dopo la birra e rimanere insieme per cena, 2ndQuadrant ha organizzato la “Elephant Pizzata”, presso il Wallace Pub Piazza Mercatale 24 (inizio dalle ore 20.30). È possibile acquistare il biglietto della cena al desk di 2ndQuadrant durante il PGDay.

Alle ore 22 circa inizierà il concerto di Nick Becattini, uno dei principali chitarristi blues del panorama italiano (aperto a tutti).

2ndQuadrant, partner “diamond” del PGDay, sarà presente con il team italiano al completo e presenterà i seguenti talk:

• Monitoraggio di PostgreSQL in un ambiente devops – Francesco Canovai
• Teoremi sociali con PostgreSQL – Gianni Ciolli, con Marco Maggesi e Alberto Mancini dell’Università di Firenze
• Implementare un sistema di Audit con il Logical Decoding – Gianni Ciolli
• PostgreSQL 9.4 per devops – Gabriele Bartolini
• HSTORE, JSON e JSONB: dati non strutturati ad alte performance – Marco Nenciarini
• Uso degli indici nei database geospaziali con PostgreSQL – Giuseppe Broccolo
• Implementare uno scheduler in User Space – Gianni Ciolli

Simon Riggs, Fondatore e CTO di 2ndQuadrant e major developer e committer del progetto PostgreSQL, presenterà lo stato attuale di “BDR (Bi-Directional Replication)”, interamente progettata e sviluppata dal team di 2ndQuadrant e disponibile in modalità open source.

A dare il via alla manifestazione, Gabriele Bartolini, Managing Director di 2ndQuadrant Italia, con il suo Keynote.

Il personale di 2ndQuadrant sarà felice di accogliervi al desk per qualsiasi informazione.

Vi aspettiamo numerosi.