L’estensione pgespresso, concepita dal nostro Simon Riggs, consentiva di marcare l’inizio e la fine del processo di backup anche su uno standby in sola lettura. Tramite pgespresso, gli utenti di Barman possono eseguire backup fisici via rsync/Ssh da un server in standby, scaricando la reale copia dal server master.

Questa funzionalità è chiamata backup concorrente ed è già disponibile in PostgreSQL attraverso il protocollo di streaming replication, via pg_basebackup.

La nuova API di PostgreSQL 9.6

L’ultima versione che pgespresso supporterà in termini di backup concorrente è PostgreSQL 9.6. Per quale motivo?

La API che PostgreSQL mette a disposizione per eseguire backup fisici di basso livello è stata estesa in modo da supportare nativamente il backup concorrente (o meglio, dovrei usare il termine “non esclusivo”). Non sono sicuro se Magnus (l’autore di questa patch) sia stato ispirato da pgespresso oppure no, ma ciò che conta è che il suo contributo sia più generico e robusto (dopo tutto, pgespresso è stato progettato per interagire soltanto con Barman).

Pertanto, PostgreSQL 9.6 e versioni future avranno al loro interno funzioni che permetteranno a Barman di richiedere un backup concorrente, rendendo pgespresso non più necessario.

Per maggiori dettagli su questa nuova API, ti consiglio di leggere la sezione che ho scritto nella pagina in inglese del Wiki di PostgreSQL “What’s new in PostgreSQL 9.6”. Per adesso, è importante sapere che:

• pg_start_backup() è stata modificata e un nuovo parametro adesso permette di specificare se il backup è esclusivo (default, per retro-compatibilità) oppure no;
• una nuova versione di pg_stop_backup() è stata fornita per i backup concorrenti: da un punto di vista tecnico, questa funzione adesso ritorna il contenuto della backup label e la mappa dei tablespace disponibili.

Barman e il backup concorrente di PostgreSQL 9.6

La cosa rilevante per i nostri cari utenti di Barman è che quest’ultimo gestirà in modo trasparente la nuova API, senza alcun impatto a livello di esperienza utente.

Di default, Barman richiederà un backup esclusivo (utilizzando le funzioni classiche disponibili sin da PostgreSQL 8). Ad ogni modo, puoi scatenare il nuovo comportamento impostando concurrent_backup nell’opzione globale/per server chiamata backup_options, come segue:

backup_options = concurrent_backup

In futuro, PostgreSQL dismetterà le funzioni per il backup esclusivo in favore di quelle per il concorrente, principalmente a causa di alcuni casi limite potenzialmente pericolosi. In particolare, la morte improvvisa di un server PostgreSQL prima di invocare pg_start_backup(), evento che lascia un file backup_label nella directory PGDATA e che impedisce al server di ripartire (e comunque, il comando barman check opportunamente configurato nel tuo sistema di monitoraggio e alerting è in grado di identificare questo problema).

Quando la nuova API per i backup diventerà quella principale per PostgreSQL, Barman agirà di conseguenza. Nel frattempo, ti invito a testare questa nuova funzionalità, attualmente disponibile solo su Github e che farà parte di Barman 1.6.2/1.7.0. Grazie!

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.

La partecipazione all’evento è gratuita, è richiesta solamente la registrazione. Gli iscritti sono 145, ma chi volesse partecipare e non si è ancora iscritto, è comunque il benvenuto.

La Conferenza è stata organizzata anche grazie al supporto dei nostri partner: HP ed IBM .

Il programma

12 maggio

Simon Riggs (fondatore di 2ndQuadrant, Code Committer e Major Developer del progetto PostgreSQL) e Gabriele Bartolini (Managing Director di 2ndQuadrant Italia e Principal Consultant per PostgreSQL) apriranno la conferenza con la presentazione di 2ndQuadrant: la storia, il contributo al codice sorgente di PostgreSQL, oltre ad una panoramica dei progetti su cui attualmente il team è impegnato, senza tralasciare lo spazio a quello che è il futuro di  PostgreSQL.
Le aziende che si affacciano oggi al mondo open source ed in modo particolare a PostgreSQL, temono di non trovare all’interno del suo ecosistema il giusto supporto specialistico. Simon e Gabriele parleranno anche dei servizi per le aziende e le organizzazioni che operano in ambienti di business continuity.

Durante la giornata si discuterà di:

• HP Helion:  Now cloud runs through your business – Rinaldo Bergamini
• The State of PostgreSQL Database 2015 – Gianni Ciolli
• Performance Archaeology – Tomas Vondra
• How we fixed bugs and rescued data – Harald Armin Massa
• Hello World! (Subito.it) – Marco Cupidi e Pietro Partescano
• JSONB type performance in PostgreSQL 9.4 – Marco Nenciarini

Infine, alle ore 17 sarà data possibilità di presentare lightning talk cioè un talk breve, della durata di massimo 5 minuti tramite cui i partecipanti avranno la possibilità di far conoscere (e farsi conoscere), divulgare, discutere, seppur brevemente, un proprio progetto, un’idea o un’esperienza relativa a PostgreSQL.

La giornata si concluderà con l’Elephant Dinner, un’ulteriore occasione per conoscerci e divertirsi tutti insieme!

13 maggio

La seconda e ultima giornata del “5432 …Meet-Us” si aprirà con il keynote di Gabriele Bartolini (Managing Director di 2ndQuadrant Italia e Principal Consultant per PostgreSQL). Gabriele illustrerà l’impatto dei principi provenienti dal manifatturiero (Lean),  della cultura devops, dell’essere agile in un mondo in continuo cambiamento e del Kanban sul lavoro quotidiano di tutto il team di 2ndQuadrant Italia. Per la prima volta, 2ndQuadrant Italia apre le porte dei propri uffici a partner esistenti e futuri, svelando le modalità impiegate.

A seguire i talk:

• IBM for Open Source Community Projects – Andrea Vercellini e Sebastien Chabrolles
• The Future of PostgreSQL Multi-Master Replication – Simon Riggs e Petr Jelinek
• PostgreSQL on EXT3/4, XFS, ZFS and BTRFS – Tomas Vondra
• PostgreSQL Disaster Recovery with Barman – Gabriele Bartolini
• PostgreSQL Online Upgrades and Maintenance – Petr Jelinek
• repmgr 3 – Gianni Ciolli
• PostgreSQL configuration management with Puppet – Francesco Canovai e Giuseppe Broccolo

In chiusura, verranno estratti a sorteggio i vincitori del concorso a premi! Per la prima volta 2ndQuadrant Italia ha deciso di mettere in palio a due partecipanti i corsi di formazione: BDR e Barman che si terranno il 14 maggio. Al desk, durante la registrazione, ognuno riceverà un coupon numerato. Una parte del tagliando verrà inserito in un contenitore da utilizzare per l’estrazione. Oltre ai corsi, ci sono altri premi “minori” come libri e gadgets.

Alle ore 20.30 un’altra occasione per stare insieme: “Let’s network!” una cena per non dirci “addio”, ma “a presto”!

Oltre la conferenza

Il programma di eventi collaterali e attività organizzate al di fuori della Conferenza, offre un’eccellente opportunità per i partecipanti di discutere i temi intorno PostgreSQL, per conoscerci e divertirsi tutti insieme. Consulta i side events!

Inoltre, il 14 maggio si svolgerà la prima edizione dei corsi su:

• PostgreSQL Bi-Directional Replication (BDR)
• Barman – Disaster Recovery tool

È possibile iscriversi ai corsi sul sito della conferenza: PostgreSQL training.

Vi aspettiamo numerosi il 12 e 13 maggio a Milano!

Approfondiamo le principali novità di quest’anno, ricordando che la partecipazione è gratuita ed è richiesta soltanto la registrazione.

PostgreSQL Training

Il 14 maggio, subito dopo l’evento, si svolgerà la prima edizione dei corsi di Barman e di Replica Bi-Direzionale (BDR)

Entrambi i corsi faranno parte dei premi che saranno messi in palio nell’estrazione prevista a chiusura della conferenza.

I due fortunati estratti tra i partecipanti alla conferenza, avranno l’opportunità di seguire gratuitamente o il corso di Barman o il corso di Replica Bi-Direzionale (BDR).

Barman Training

Uno dei componenti della business continuty è la disaster recovery. Per PostgreSQL è sempre più utilizzato Barman (Backup e Recovery Manager), un tool open source, sviluppato e manutenuto da 2ndQuadrant.

Barman è stato sviluppato sulla base di 3 principi fondamentali: Integrazione, Usabilità, Automazione.

Il corso, tenuto da chi Barman lo ha progettato e sviluppato, spiegherà come utilizzare Barman nel migliore dei modi, guidando i partecipanti ad un adeguato piano di Disaster Recovery.
Iscriviti al corso su Barman!

Bi-Directional Replication (BDR) Training

Dalla versione 9.0, la comunità di PostgreSQL ha aggiunto molte feature inerenti la replica, tra cui la replica asincrona in streaming, la replica sincrona, replica a cascata e fast-failover.

In PostgreSQL 9.4 è stata aggiunta la possibilità di eseguire la replica di logica, che ha aperto la strada a nuove opportunità che porteranno alla replica multi-master nativa in PostgreSQL. Il contributo di 2ndQuadrant è la Replica Bi-Direzionale o BDR.

Il corso sarà tenuto dallo sviluppatore Petr Jelinek e sarà focalizzato sulla BDR / UDR e tratterà anche argomenti come:

• Le diverse modalità di replica presenti in PostgreSQL 9.4;
• Le migliori pratiche per la creazione e la gestione della replica con PostgreSQL;
• Configurazione della replica logica e replica bidirezionale in PostgreSQL 9.4.

Iscriviti al corso sulla BDR!

One-to-One

Durante la conferenza è possibile organizzare un meeting One-to-One con Simon Riggs, Gabriele Bartolini e Gianni Ciolli.

Questa è una grande opportunità per chiarire dubbi o approfondire aspetti di PostgreSQL, specifici ed inerenti la vostra realtà, con tre dei massimi esperti di PostgreSQL, nonché autori della seconda edizione del libro “PostgreSQL Administration Cookbook” (in uscita con Packt).

Per prenotare l’incontro è necessario procedere con l’iscrizione e verrete contattati per definire insieme l’orario. Pochi i posti disponibili, affrettatevi!

2ndQuadrant ed il Kanban

Nel 2013 abbiamo incontrato Dragos Dumitriu, pioniere del Kanban in ambito IT, ed è nata una bella amicizia.
Dragos sarà con noi a Milano e terrà il corso di Kanban nelle giornate del 14 e 15 maggio.

Kanban è una metodologia a supporto dei Team IT. Tale metodologia, ispirata ai principi dello sviluppo software agile e lean, permette di:

• Visualizzare il flusso di lavoro;
• Limitare il Work-in-Progress;
• Misurare e gestire il flusso;
• Rendere le politiche di processo esplicite;
• Utilizzare i modelli per riconoscere le opportunità di miglioramento.

È un’opportunità davvero rara quella di seguire il workshop di Kanban tenuto direttamente da Dragos Dumitriu!

Oltre la conferenza: Let’s Network!

Altre le opportunità di network, come l’inevitabile “Elephant Dinner”, attualmente in fase di organizzazione.
Invitiamo tutti gli interessati a restare aggiornati sugli sviluppi della conferenza “5 4 3 2 … MeetUs!” attraverso il nostro sito internet o a seguirci su  Twitter e Linkedin.

Vi aspettiamo numerosi il 12 e 13 maggio a Milano!

Da quest’anno, PyCon Italia diventa un evento politematico ed accoglie le subcommunity più importanti all’interno dell’universo Python: PyData, DjangoVillage e Odoo Italian Community

2ndQuadrant Italia parteciperà alla conferenza con i talk di Gabriele Bartolini, Marco Nenciarini e Giulio Calacoci. Consulta il programma dell’evento.

PostgreSQL 9.4 per devops

Di Gabriele Bartolini
Venerdì 17 aprile alle 12:00, lingua inglese – Domenica 19 aprile alle 9:30, lingua italiana

Il database relazionale open source più avanzato al mondo non smette di migliorarsi. Scopri le novità introdotte nella versione 9.4 di PostgreSQL, opportunamente classificate in un’ottica devops, ed in particolare:

• replica logica in streaming, il primo passo per replica bidirezionale e multi-master;
• supporto per il tipo di dato JSONB, per la felicità degli amanti dei database NoSQL;
• refresh concorrente di viste materializzate, per gli amanti dei data warehouse.

Odoo disaster recovery con Barman

Di Giulio Calacoci
Sabato 18 aprile alle 12:15

Sei stufo di gestire i processi di backup e recovery dei tuoi server PostgreSQL facendo uso di script ‘ad hoc’?
Hai paura di poter essere svegliato nel cuore della notte o peggio mentre sei in vacanza, per eseguire il ripristino di uno dei server critici per il business della tua ditta?
Barman, Backup e Recovery Manager, standardizza le operazioni di backup e recovery, permettendo agli amministratori di database e agli amministratori di sistema di integrare facilmente all’interno del loro piano di disaster recovery le soluzioni basate su Odoo.

HSTORE, JSON e JSONB: dati non strutturati ad alte performance

Di Marco Nenciarini
Sabato 18 aprile alle 15:45

Nelle ultime release di PostgreSQL è stato fatto un enorme lavoro sui dati non strutturati, culminato con l’aggiunta del tipo JSONB. Insieme a JSON, HSTORE e array fornisce una potenza mai vista per le proprie applicazione web e non solo. In questo talk si passeranno in rassegna alcuni dei possibili casi d’uso e si illustreranno i vantaggi delle varie possibilità.

Il progetto Barman: Open Source, Team, devops, kanban, PostgreSQL e Python

Di Gabriele Bartolini e Marco Nenciarini
Domenica 19 aprile alle 11:45

Barman è un software open source per la disaster recovery di database PostgreSQL, probabilmente, in questo momento, il tool più utilizzato al mondo per questo scopo.
È un progetto open source nato nel 2012, scritto in Python e totalmente sviluppato in Italia.
In questo talk vogliamo condividere i processi di sviluppo e le tecnologie impiegati in 2ndQuadrant per lo sviluppo di Barman e l’importanza fondamentale della collaborazione fra tutti i membri del team, grazie a cultura devops, kanban, metodologie agili, pair programming, testing, ecc.

L’intero codice usato in questo tutorial è presente su GitHub all’indirizzo https://github.com/2ndquadrant-it/vagrant-puppet-barman.

Configurare il Puppet Master: Vagrant

Innanzitutto, occorre modificare il Vagrantfile per avviare una terza macchina, chiamata puppet, che sarà il nostro Puppet Master. Questa macchina dovrà essere subito raggiungibile dagli agenti Puppet presenti su ognuna delle VM create, per cui, all’interno del primo script che lanciamo, configuriamo una entry per il suo indirizzo in /etc/hosts.

Sempre nello script inline dobbiamo abilitare l’agente Puppet. Questo è infatti disabilitato di default nelle distribuzioni derivate da Debian.

Infine, all’interno del Vagrantfile, andiamo ad effettuare una distinzione fra master e agenti. Il primo caricherà la propria configurazione direttamente da file, gli agenti lo faranno chiedendola al master e inviandogli i dati che devono scambiarsi con gli altri nodi. Per quest’ultima ragione un agente è impostato per girare anche sul master.

Il Vagrantfile prodotto è il seguente:

Vagrant.configure("2") do |config|
  {
    :puppet => {
      :ip      => '192.168.56.220',
      :box     => 'ubuntu/trusty64',
      :role    => 'master'
    },
    :pg => {
      :ip      => '192.168.56.221',
      :box     => 'ubuntu/trusty64',
      :role    => 'agent'
    },
    :backup => {
      :ip      => '192.168.56.222',
      :box     => 'ubuntu/trusty64',
      :role    => 'agent'
    }
  }.each do |name,cfg|
    config.vm.define name do |local|
      local.vm.box = cfg[:box]
      local.vm.hostname = name.to_s + '.local.lan'
      local.vm.network :private_network, ip: cfg[:ip]
      family = 'ubuntu'
      bootstrap_url = 'https://raw.github.com/hashicorp/puppet-bootstrap/master/' + family + '.sh'

      # Run puppet-bootstrap and enable the Puppet agent
      local.vm.provision :shell, :inline => <<-eos
        if [ ! -e /var/tmp/.bash.provision.done ]; then
          echo "192.168.56.220  puppet.local.lan        puppet puppetdb puppetdb.local.lan" >> /etc/hosts
          curl -L #{bootstrap_url} | bash
          puppet agent --enable
          touch /var/tmp/.bash.provision.done
        fi
      eos

      if cfg[:role] == 'master'
        # Puppet master needs RAM
        local.vm.provider "virtualbox" do |v|
          v.memory = 1024
        end

        # Provision the master with Puppet
        local.vm.provision :puppet do |puppet|
          puppet.manifests_path = "manifests"
          puppet.module_path = [".", "modules"]
          puppet.manifest_file = "site.pp"
          puppet.options = [
           '--verbose',
          ]
        end
      end

      # Puppet agents should be provisioned by the master
      local.vm.provision :puppet_server do |puppet|
        puppet.options = [
         '--verbose',
        ]
      end

    end
  end
end

Configurare il Puppet Master: Puppet

Una volta in possesso del Vagrantfile è il momento di andare a modificare il manifesto Puppet per attivare il master.
Prima di fare questo, però, è necessario installare altri due moduli: puppetlabs/puppetdb e stephenrjonson/puppet.

puppetlabs/puppetdb configura PuppetDB. PuppetDB utilizza un database PostgreSQL per raccogliere i fatti e le risorse esportate dai vari nodi dell’infrastruttura, in modo che questi possano scambiarsi informazioni e configurarsi uno in base agli altri.
stephenrjonson/puppet permette di configurare un server Puppet Master con Apache e Passenger, nonché di configurare gli agenti sui vari nodi della rete.

Modifichiamo quindi il Puppetfile in:

forge 'https://forgeapi.puppetlabs.com'
mod 'it2ndq/barman'
mod 'puppetlabs/postgresql'
mod 'puppetlabs/puppetdb'
mod 'stephenrjohnson/puppet'

Rispetto all’articolo precedente abbiamo rimosso la dipendenza dall’ultima versione su GitHub per il modulo it2ndq/barman, del quale è stata rilasciata la versione 1.0.0 (che utilizzeremo) negli ultimi giorni. Eseguiamo:

$ librarian-puppet install --verbose

A questo punto possiamo andare a modificare il manifesto site.pp, aggiungendo il nodo puppet e inserendo al suo interno il seguente frammento di codice per PuppetDB e il Puppet Master:

  # Setup PuppetDB
  class { 'puppetdb': }->
  # Setup Puppet Master, Apache and Passenger
  class { 'puppet::master':
    storeconfigs => true,
    autosign     => true,
    environments => 'directory',
  }->

Abbiamo così configurato il Puppet Master per accettare automaticamente connessioni da tutte le macchine (autosign) e distribuire i cataloghi, i fatti e le risorse esportate (storeconfig).
Infine, utilizziamo i directory environment di Puppet per distribuire il catalogo agli agenti. La directory standard per gli ambienti è /etc/puppet/environments e l’ambiente di default è production. Inseriamo quindi i nostri manifesti e moduli al suo interno. Poiché Vagrant già condivide la directory in cui si trova il Vagrantfile con le macchine create, possiamo fare un link simbolico a questa directory:

  # Have the manifest and the modules available for the master to distribute
  file {
    ['/etc/puppet/environments', '/etc/puppet/environments/production']:
      ensure => directory;
    '/etc/puppet/environments/production/modules':
      ensure => 'link',
      target => '/vagrant/modules';
    '/etc/puppet/environments/production/manifests':
      ensure => 'link',
      target => '/vagrant/manifests';
  }

A questo punto, su ogni nodo dell’infrastruttura, dovremo configurare l’agente. Esplicitiamo il Puppet Master, l’environment e il modo in cui deve essere eseguito. Eseguire l’agente via cron occupa meno risorse che farlo girare come demone:

  # Configure Puppet Agent
  class { 'puppet::agent':
    puppet_run_style => 'cron',
    puppet_server    => 'puppet.local.lan',
    environment      => 'production',
  }

Iniziamo adesso a condividere risorse fra i vari nodi. Poiché i nodi pg e backup avranno bisogno di comunicare fra loro via SSH, dovranno sapere qual è l’ip dell’altro server e averne la chiave all’interno di known_hosts. Provvediamo quindi ad esportare e raccogliere queste risorse su ogni nodo, ad esempio:

  @@host { 'backup_host':
    ensure       => 'present',
    name         => $::fqdn,
    host_aliases => $::hostname,
    ip           => '192.168.56.222',
  }

  @@sshkey { "${::hostname}_ecdsa":
    host_aliases => [ $::hostname, $::fqdn ],
    type         => 'ecdsa-sha2-nistp256',
    key          => $::sshecdsakey,
  }

  # Collect:
  Host <<| |>>
  Sshkey <<| |>>

barman::autoconfigure

Adesso, siamo liberi di andare a configurare il server PostgreSQL e il server Barman. Con la possibilità di usare l’autoconfigure, questa parte diventa molto più semplice rispetto all’articolo precedente.

Per il nodo backup basta infatti indicare di usare l’autoconfigure e quale ip deve esportare. La macchina Vagrant infatti possiede due indirizzi ip e noi dobbiamo forzare l’utilizzo di 192.168.56.222. Inoltre, andiamo a usare il pacchetto di PGDG, abilitando manage_package_repo:

  class { 'barman':
    autoconfigure       => true,
    exported_ipaddress  => '192.168.56.222/32',
    manage_package_repo => true,
  }

Sul nodo pg provvediamo a installare il server PostgreSQL e a dichiarare come -il server PostgreSQL- debba essere gestito da Barman, attraverso la classe barman::postgres. Questa classe esporta il cron per l’esecuzione del comando barman backup pg e la configurazione del server per Barman, che saranno importati dal server backup tramite autoconfigure:

  # Configure PostgreSQL
  class { 'postgresql::server':
    listen_addresses     => '*',
  }

  # Export the parameters required by Barman
  class { 'barman::postgres':
    retention_policy        => 'RECOVERY WINDOW OF 1 WEEK',
    minimum_redundancy      => 1,
    last_backup_maximum_age => '1 WEEK',
    reuse_backup            => 'link',
    backup_hour             => 1,
    backup_minute           => 0,
  }

Test

È possibile testare tutto quello che abbiamo visto finora clonando il progetto su GitHub ed eseguendo, all’interno della directory creata:

$ librarian-puppet install --verbose
$ vagrant up
$ vagrant provision
$ vagrant provision

Il sistema deve infatti effettuare tre provision (il primo è all’interno del primo vagrant up) prima che tutte le risorse esportate siano raccolte dai nodi. A questo punto possiamo entrare nella macchina backup e controllare che il backup possa essere effettuato:

$ vagrant ssh backup
root@backup:~# barman backup all
Starting backup for server pg in /var/lib/barman/pg/base/20150320T114208
Backup start at xlog location: 0/2000028 (000000010000000000000002, 00000028)
Copying files.
Copy done.
Backup size: 18.7 MiB. Actual size on disk: 18.7 MiB (-0.00% deduplication ratio).
Asking PostgreSQL server to finalize the backup.
Backup end at xlog location: 0/20000B8 (000000010000000000000002, 000000B8)
Backup completed
Processing xlog segments for pg
        Older than first backup. Trashing file 000000010000000000000001 from server pg
        000000010000000000000002
        000000010000000000000002.00000028.backup

Conclusioni

Anche se la configurazione iniziale di un Puppet Master può essere laboriosa, i vantaggi sono enormi. Non solo la configurazione di Barman è più semplice, ma qualunque altra aggiunta all’infrastruttura ne risulta estremamente semplificata. Ad esempio, aggiungere un server Icinga o Nagios diventa molto più semplice quando ogni singolo server può esportare i servizi che devono essere monitorati (check_postgres o barman check --nagios).

Inoltre, nell’esempio abbiamo utilizzato un solo server PostgreSQL e un solo server Barman, ma in caso di infrastrutture complesse con molti database server è possibile dichiarare più server Barman e utilizzare host_group per identificare i server Postgres dei quali i diversi server Barman devono fare il backup.

Concludo con un ringraziamento speciale a Alessandro Franceschi per l’idea iniziale di aggiungere un sistema di autoconfigurazione al modulo Barman.

Una full immersion di due giorni su PostgreSQL, con testimonianze dirette delle aziende lo hanno adottato, possibilità di presentare lightning talk e soprattutto sarà l’occasione per interagire apertamente con il nostro team, primo fra tutti con Simon Riggs, fondatore di 2ndQuadrant, Code Committer e Major Developer del progetto PostgreSQL.

L’evento si terrà in via privata Stefanardo da Vimercate 28, a pochi passi dalla fermata Gorla M1, presso Enter.
La partecipazione è gratuita ma è richiesta la registrazione: vi aspettiamo numerosi!

Per maggiori informazioni scrivete a eventi@2ndquadrant.it oppure consultate il sito della conferenza http://5432.2ndquadrant.it.

Perché “5432”?

Il titolo dell’evento non è stato scelto a caso. 5432 è infatti la porta TCP sulla quale è tipicamente in ascolto un server PostgreSQL. Come PostgreSQL, a Milano noi saremo pronti, in ascolto, per rispondere alle domande e fugare le curiosità di tutti i partecipanti.

Oltre la conferenza: Barman e BDR Training

Finalmente Barman e BDR faranno parte del catalogo corsi. La prima edizione dei corsi si svolgerà subito dopo l’evento, il 14 maggio:

• Barman, tenuto da Gabriele Bartolini
• Bi-Directional Replication (BDR) Training, tenuto da Petr Jelinek

Iscriversi è facile ed è possibile attraverso il sito della conferenza.

Molte le opportunità di interazione

Simon Riggs e Gabriele Bartolini saranno a vostra disposizione per meeting privati durante la conferenza.
Quesiti specifici, inerenti la vostra realtà, potranno essere esposti in totale riservatezza.
Per prenotare lo spazio basterà scrivere a eventi@2ndquadrant.it. Pochi i posti disponibili.

Altre le opportunità di incontro, come l’immancabile “Elephant Dinner”.
Per restare aggiornati consultate il sito web della conferenza o scrivete a eventi@2ndquadrant.it

Puppet: configurazione

Dopo aver definito le macchine come nell’articolo precedente, occorre definire i moduli Puppet necessari, che lasceremo gestire a librarian-puppet.

I moduli sono due:

1. puppetlabs/postgresql (https://github.com/puppetlabs/puppetlabs-postgresql/) per installare PostgreSQL sulla VM pg
2. it2ndq/barman (https://github.com/2ndquadrant-it/puppet-barman) per installare Barman su backup.

Per il primo useremo la versione presente su Puppet Forge, per il secondo effettueremo il clone da GitHub del progetto, per poterne sfruttare le modifiche più recenti.

Creiamo nella directory corrente un file chiamato Puppetfile con questo contenuto:

forge "https://forgeapi.puppetlabs.com"
mod "puppetlabs/postgresql"
mod "it2ndq/barman", :git => "git://github.com/2ndquadrant-it/puppet-barman.git"

Possiamo ora installare il modulo Puppet e le sue dipendenze eseguendo:

$ librarian-puppet install --verbose

Per quanto non indispensabile, il consiglio è quello di utilizzare sempre l’opzione --verbose ogni volta che si usa librarian-puppet.  Il comando è molto silenzioso ed è bene avere dettagli su quello che sta facendo, prima di scoprire (ad esempio) di avere buttato tempo prezioso aspettando che risolvesse senza successo un complicato conflitto di dipendenze.

Al completamento del comando, all’interno della directory corrente sarà presente la nuova directory modules che conterrà i moduli richiesti (barman, postgresql) e le loro dipendenze (apt, concat, stdlib). Inoltre, sarà stato creato il file Puppetfile.lock, che identifica dipendenze e versioni dei moduli installati, fissandole a protezione di aggiornamenti futuri. In questo modo, i successivi librarian-puppet install installeranno le stesse identiche versioni definite nel Puppetfile.lock, invece di possibili aggiornamenti.

A questo punto, aggiungiamo alla configurazione di Vagrant il fatto di utilizzare un manifesto Puppet per effettuare il provisioning dei server al termine dell’installazione di Puppet.
Modifichiamo quindi il Vagrantfile in questo modo:

Vagrant.configure("2") do |config|
  {
    :pg => {
      :ip      => '192.168.56.221',
      :box     => 'ubuntu/trusty64'
    },
    :backup => {
      :ip      => '192.168.56.222',
      :box     => 'ubuntu/trusty64'
    }
  }.each do |name,cfg|
    config.vm.define name do |local|
      local.vm.box = cfg[:box]
      local.vm.hostname = name.to_s + '.local.lan'
      local.vm.network :private_network, ip: cfg[:ip]
      family = 'ubuntu'
      bootstrap_url = 'https://raw.github.com/hashicorp/puppet-bootstrap/master/' + family + '.sh'

      # Run puppet-bootstrap only once
      local.vm.provision :shell, :inline => <<-eos
        if [ ! -e /tmp/.bash.provision.done ]; then
          curl -L #{bootstrap_url} | bash
          touch /tmp/.bash.provision.done
        fi
      eos

      # Provision with Puppet
      local.vm.provision :puppet do |puppet|
        puppet.manifests_path = "manifests"
        puppet.module_path = [".", "modules"]
        puppet.manifest_file = "site.pp"
        puppet.options = [
         '--verbose',
        ]
      end
    end
  end
end

Con le linee che abbiamo appena aggiunto, abbiamo dato a Vagrant l’istruzione di effettuare il provision delle macchine a partire dal file manifests/site.pp e che i moduli necessari al manifesto sono da cercare all’interno della directory modules. Il Vagrantfile è adesso nella sua forma definitiva.
Creiamo perciò la directory manifests all’interno della nostra directory di lavoro:

$ mkdir manifests

Andiamo quindi a scrivere in manifests una prima versione di site.pp, iniziando con una configurazione di default.

node backup {
  class { 'barman': 
    manage_package_repo => true,
  }
}
node pg {}

A questo punto, avviamo le due macchine virtuali. Se le avete distrutte al termine dell’articolo precedente, tutto quello che serve è eseguire:

$ vagrant up

Altrimenti, se le macchine sono ancora attive, occorreranno i comandi:

$ vagrant reload
$ vagrant provision

Possiamo osservare che sulla VM è stato creato un server Barman con una configurazione di base, senza alcun server configurato, connettendoci

$ vagrant ssh backup

e controllando il contenuto del file /etc/barman.conf:

# Main configuration file for Barman (Backup and Recovery Manager for PostgreSQL)
# Further information on the Barman project at www.pgbarman.org
# IMPORTANT: Please do not edit this file as it is managed by Puppet!
# Global options

[barman]
barman_home = /var/lib/barman
barman_user = barman
log_file = /var/log/barman/barman.log
compression = gzip
backup_options = exclusive_backup
minimum_redundancy = 0
retention_policy =
retention_policy_mode = auto
wal_retention_policy = main
configuration_files_directory = /etc/barman.conf.d

Procediamo adesso ad avviare un server PostgreSQL sulla macchina virtuale pg, modificando il site.pp. Dobbiamo tenere presente di quali siano i parametri richiesti da Barman al server, per cui dovremo impostare:

• wal_level almeno a livello archive
• archive_mode a on
• archive_command in modo che i WAL possano essere copiati su Barman
• una regola nel pg_hba.conf per consentire l’accesso al database dal server backup

Tutti questi parametri sono facilmente configurabili attraverso il modulo puppetlabs/postgresql.

Inoltre, aggiungiamo i parametri minimi di configurazione per il backup del server PostgreSQL pg sul nodo backup. Avremo bisogno di:

• una stringa di connessione PostgreSQL
• un file .pgpass per l’autenticazione
• un comando per connettersi via SSH
• effettuare lo scambio delle chiavi SSH.

it2ndq-barman genera automaticamente una coppia di chiavi pubblica/privata in ~barman/.ssh/. Scambiare in automatico le chiavi richiede la presenza di un puppet master per l’esportazione delle risorse. Configurare un puppet master è fuori dagli obiettivi di questo tutorial (ma sarà parte del prossimo, incentrato proprio sull’utilizzo di un puppet master e della classe barman::autoconfigure), quindi questo ultimo passo sarà eseguito manualmente.
Modifichiamo quindi il file site.pp come segue:

node backup {
  class { 'barman': 
    manage_package_repo => true,
  }
  barman::server {'test-server':
    conninfo     => 'user=postgres host=192.168.56.221',
    ssh_command  => 'ssh postgres@192.168.56.221',
  }
  file { '/var/lib/barman/.pgpass':
    ensure  => 'present',
    owner   => 'barman',
    group   => 'barman',
    mode    => 0600,
    content => '192.168.56.221:5432:*:postgres:insecure_password',
  }
}

node pg {
  class { 'postgresql::server':
    listen_addresses  => '*',
    postgres_password => 'insecure_password',
    pg_hba_conf_defaults => false,
  }
  postgresql::server::pg_hba_rule {'Local access':
    type        => 'local',
    database    => 'all',
    user        => 'all',
    auth_method => 'peer',
  }
  postgresql::server::pg_hba_rule {'Barman access':
    type        => 'host',
    database    => 'all',
    user        => 'postgres',
    address     => '192.168.56.222/32',
    auth_method => 'md5',
  }
  postgresql::server::config_entry {
    'wal_level'       : value => 'archive';
    'archive_mode'    : value => 'on';
    'archive_command' : value => 'rsync -a %p barman@192.168.56.222:/var/lib/barman/test-server/incoming/%f';
  }
  class { 'postgresql::server::contrib':
    package_ensure => 'present',
  }
}

Avendo modificato la configurazione delle macchine, è necessario rieseguire il provision:

$ vagrant provision

Quando le macchine sono su, possiamo procedere allo scambio di chiavi. Connettiamoci a pg:

$ vagrant ssh pg

e creiamo le chiavi per l’utente postgres, lasciando vuoto ogni campo durante l’esecuzione di ssh-keygen (ovvero, premendo sempre invio):

vagrant@pg:~$ sudo -iu postgres
postgres@pg:~$ ssh-keygen
postgres@pg:~$ cat .ssh/id_rsa.pub

L’ultimo comando emette una lunga stringa alfanumerica che deve essere inserita nel file ~barman/.ssh/authorized_keys su backup.

$ vagrant ssh backup
vagrant@backup:~$ sudo -iu barman
barman@backup:~$ echo "ssh-rsa ..." >> .ssh/authorized_keys

Allo stesso modo, copiamo la chiave dell’utente barman nel file authorized_keys dell’utente postgres su pg:

barman@backup:~$ cat .ssh/id_rsa.pub
ssh-rsa ...
barman@backup:~$ logout
vagrant@backup:~$ logout
$ vagrant ssh pg
vagrant@pg:~$ sudo -iu postgres
postgres@pg:~$ echo "ssh-rsa ..." >> .ssh/authorized_keys

A questo punto, facciamo una prima connessione in entrambe le direzioni fra i due server:

postgres@pg:$ ssh barman@192.168.56.222
barman@backup:$ ssh postgres@192.168.56.221

Eseguiamo un barman check per verificare il corretto funzionamento di Barman:

barman@backup:~$ barman check all
Server test-server:
        ssh: OK
        PostgreSQL: OK
        archive_mode: OK
        archive_command: OK
        directories: OK
        retention policy settings: OK
        backup maximum age: OK (no last_backup_maximum_age provided)
        compression settings: OK
        minimum redundancy requirements: OK (have 0 backups, expected at least 0)

Ogni riga dovrebbe risultare OK. Adesso, per effettuare un backup, basterà lanciare:

barman@backup:$ barman backup test-server

Una configurazione realistica

La configurazione di Barman effettuata finora è molto semplice, ma è facilmente possibile aggiungere pochi parametri al site.pp per sfruttare al meglio tutte le feature di Barman, come le retention policy e il nuovo backup incrementale disponibile con Barman 1.4.0.

Concludiamo questo tutorial con un caso d’uso realistico, in cui i requisiti sono:

• un backup ogni notte alle 1:00;
• avere la possibilità  di effettuare una Point In Time Recovery in un qualunque istante di tempo nell’ultima settimana;
• avere sempre almeno un backup disponibile;
• segnalare un errore durante barman check nel caso il backup più recente sia più vecchio di una settimana;
• attivare il backup incrementale per risparmiare spazio su disco.

Usiamo quindi la risorsa file di Puppet per creare un .pgpass con i parametri di connessione al db e la risorsa cron per generare il job da ripetere ogni notte. Infine, modifichiamo il barman::server per aggiungere i parametri Barman necessari.
Il risultato finale è quello che segue:

node backup {
  class { 'barman':
    manage_package_repo => true,
  }
  barman::server {'test-server':
    conninfo                => 'user=postgres host=192.168.56.221',
    ssh_command             => 'ssh postgres@192.168.56.221',
    retention_policy        => 'RECOVERY WINDOW OF 1 WEEKS',
    minimum_redundancy      => 1,
    last_backup_maximum_age => '1 WEEK',
    reuse_backup            => 'link',
  }
  file { '/var/lib/barman/.pgpass':
    ensure  => 'present',
    owner   => 'barman',
    group   => 'barman',
    mode    => 0600,
    content => '192.168.56.221:5432:*:postgres:insecure_password',
  }
  cron { 'barman backup test-server':
    command => '/usr/bin/barman backup test-server',
    user    => 'barman',
    hour    => 1,
    minute  => 0,
  }
}

node pg {
  class { 'postgresql::server':
    listen_addresses  => '*',
    postgres_password => 'insecure_password',
    pg_hba_conf_defaults => false,
  }
  postgresql::server::pg_hba_rule {'Local access':
    type        => 'local',
    database    => 'all',
    user        => 'all',
    auth_method => 'peer',
  }
  postgresql::server::pg_hba_rule {'Barman access':
    type        => 'host',
    database    => 'all',
    user        => 'postgres',
    address     => '192.168.56.222/32',
    auth_method => 'md5',
  }
  postgresql::server::config_entry {
    'wal_level'       : value => 'archive';
    'archive_mode'    : value => 'on';
    'archive_command' : value => 'rsync -a %p barman@192.168.56.222:/var/lib/barman/test-server/incoming/%f';
  }
}

Conclusioni

Con 51 righe esatte di Puppet siamo riusciti a configurare una coppia di server PostgreSQL/Barman con delle impostazioni molto simili a quelle che potremmo volere in produzione. Abbiamo così combinato i vantaggi dell’avere un server Barman che gestisce i backup a quelli di avere un’infrastruttura gestita da Puppet, riutilizzabile e versionabile.

Nella prossima e ultima parte di questa serie di articoli vedremo come utilizzare un Puppet master per approfittare della possibilità di esportare risorse fra macchine diverse e così permettere alle due macchine di scambiarsi i parametri necessari al loro corretto funzionamento tramite la classe barman::autoconfigure.

Obiettivo di questo articolo, sviluppato in tre parti, sarà quello di automatizzare l’installazione di Barman e di configurarlo, sempre in modo automatico, per eseguire backup da un server PostgreSQL di test.
Questa prima parte è un aggiornamento di quanto scritto da Gabriele, ma con l’idea di creare due macchine virtuali invece di una sola.

it2ndq/barman è il modulo rilasciato da 2ndQuadrant Italia per gestire l’installazione di Barman tramite Puppet. Il modulo ha licenza GPLv3 ed è disponibile su GitHub all’indirizzo https://github.com/2ndquadrant-it/puppet-barman.
La procedura che segue è stata scritta avendo come base una Ubuntu 14.04 Trusty Tahr, ma può essere eseguita in modo simile su altre distribuzioni.

I requisiti

Per avviare il modulo per Barman su una macchina virtuale, abbiamo bisogno dei seguenti software:

• VirtualBox
• Vagrant
• Ruby >= 1.9
• Puppet
• librarian-puppet

Vagrant

Vagrant è un software per la gestione di macchine virtuali in grado di supportare numerosi software di virtualizzazione, con VirtualBox come default.

Installiamo quindi VirtualBox:

$ sudo apt-get install virtualbox virtualbox-dkms

L’ultima versione di Vagrant può essere scaricata dal sito e poi installata con il comando:

$ sudo dpkg -i /path/to/vagrant_1.7.2_x86_64.deb

Ruby

Per Ruby, il consiglio è di utilizzare rbenv, che permette di crearsi un ambiente di sviluppo Ruby in cui specificare la versione da usare.
Per installare rbenv il suggerimento è quello di usare rbenv-installer (https://github.com/fesplugas/rbenv-installer) e configurare Ruby per l’utente corrente, evitando così di sporcare l’ambiente Ruby di sistema.
Scarichiamo ed eseguiamo lo script:

$ curl https://raw.githubusercontent.com/fesplugas/rbenv-installer/master/bin/rbenv-installer | bash

Al termine, lo script chiederà di aggiungere le seguenti linee all’interno del file ~/.bash_profile:

export RBENV_ROOT="${HOME}/.rbenv"

if [ -d "${RBENV_ROOT}" ]; then
  export PATH="${RBENV_ROOT}/bin:${PATH}"
  eval "$(rbenv init -)"
fi

Ricarichiamo il ~/.bash_profile appena modificato:

$ exec bash -l

A questo punto installiamo una versione di Ruby e impostiamo l’utente per usare questa versione invece che quella di sistema:

$ rbenv install 2.1.5
$ rbenv global 2.1.5

Puppet

È necessario avere Puppet installato sulla macchina host. Installiamo quindi la gemma relativa:

$ gem install puppet

librarian-puppet

Infine, librarian-puppet è un tool per automatizzare la gestione dei moduli Puppet. Anche librarian-puppet è installabile come gemma:

$ gem install librarian-puppet

Vagrant: configurazione

Adesso che abbiamo le dipendenze a posto, possiamo iniziare a scrivere le configurazioni di Vagrant e Puppet per il nostro sistema di backup.
Iniziamo creando una directory in cui lavorare:

$ mkdir ~/vagrant_puppet_barman
$ cd ~/vagrant_puppet_barman

Vagrant ha bisogno di un file chiamato Vagrantfile dove leggere le configurazioni delle VM da avviare. Procediamo quindi con la scrittura del file.

Il seguente Vagrantfile avvia due VM Ubuntu Trusty, chiamate pg e backup, con indirizzi ip rispettivamente 192.168.56.221 e 192.168.56.222. Su entrambe le macchine verrà effettuato un provisioning attraverso uno script shell definito inline all’interno del file stesso. Tale script lancia puppet-bootstrap (https://github.com/hashicorp/puppet-bootstrap), uno script che automaticamente installa e configura Puppet su vari tipi di macchine. Siccome non è necessario che sia eseguito più di una volta, nello script inline è stato inserito un test per evitare ulteriori esecuzioni.

Vagrant.configure("2") do |config|
  {
    :pg => {
      :ip      => '192.168.56.221',
      :box     => 'ubuntu/trusty64'
    },
    :backup => {
      :ip      => '192.168.56.222',
      :box     => 'ubuntu/trusty64'
    }
  }.each do |name,cfg|
    config.vm.define name do |local|
      local.vm.box = cfg[:box]
      local.vm.hostname = name.to_s + '.local.lan'
      local.vm.network :private_network, ip: cfg[:ip]
      family = 'ubuntu'
      bootstrap_url = 'https://raw.github.com/hashicorp/puppet-bootstrap/master/' + family + '.sh'

      # Run puppet-bootstrap only once
      local.vm.provision :shell, :inline => <<-eos
        if [ ! -e /tmp/.bash.provision.done ]; then
          curl -L #{bootstrap_url} | bash
          touch /tmp/.bash.provision.done
        fi
      eos
    end
  end
end

Un test

Abbiamo definito due Ubuntu contenenti Puppet. Questo non è ancora il Vagrantfile definitivo, ma già permette di creare le due macchine. Se siete curiosi, è possibile controllare che le due macchine siano effettivamente create con il comando:

$ vagrant up

e successivamente connettersi usando i comandi:

$ vagrant ssh pg
$ vagrant ssh backup

Infine, le macchine possono essere distrutte con:

$ vagrant destroy -f

Prime conclusioni

In questa prima parte di tutorial abbiamo visto come configurare le dipendenze e siamo arrivati ad avere le due macchine virtuali su cui andare a installare, via Puppet, PostgreSQL e Barman.
La scrittura del manifesto Puppet per l’installazione vera e propria sarà argomento del prossimo articolo, in uscita la prossima settimana. A presto!

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.