Feeds

FeedRSSLast fetchedNext fetched after
/var/tmp/it XML 07:01, sabato, 10 dicembre 08:01, sabato, 10 dicembre
2ndQuadrant XML 07:01, sabato, 10 dicembre 08:01, sabato, 10 dicembre
:: Luca Ferrari :: XML 07:01, sabato, 10 dicembre 08:01, sabato, 10 dicembre
Il blog di Enrico Pirozzi - Postgresql XML 07:01, sabato, 10 dicembre 08:01, sabato, 10 dicembre
Planet PostgreSQL – Denis Gasparin XML 07:01, sabato, 10 dicembre 08:01, sabato, 10 dicembre
PostgreSQL – Blog di Diego Cinelli XML 07:01, sabato, 10 dicembre 08:01, sabato, 10 dicembre

martedì, 06 dicembre

17:29

PGDay.IT 2016: cena sociale [:: Luca Ferrari ::]

Ormai manca pochissimo al prossimo PGDay.IT 2016, ed è ora ufficiale che ci sarà anche la cena sociale, con una organizzazione meno formale rispetto agli anni passati.
Se volete unirvi al gruppo che tiene in vita la conferenza fatevi trovare la sera prima dell'evento presso il locale Camelot 3.0.

mercoledì, 30 novembre

19:09

PgDay.IT 2016: keynote [:: Luca Ferrari ::]

Il programma del PgDay.IT 2016 è ormai completo: anche il keynote che anora non era stato annunciato è stato posizionato.
Ad aprire la decima edizione della conferenza italiana dedicata a PostgreSQL sarà il dott. Giorgio Roncolato, attuale direttore dei Sistemi Informativi ULSS 5 di Arzignano, dove ovviamente viene usato massivamente PostgreSQL.

sabato, 26 novembre

09:55

pgrepup – upgrade PostgreSQL using logical replication [Planet PostgreSQL – Denis Gasparin]

pgrepup is a tool written in Python for upgrading a PostgreSQL cluster to a new major version using logical replication and pglogical extension.

pgrepup simplifies the setup of 2nd Quadrant’s pglogical extension giving hints for configuring correctly source and destination pgsql clusters.

The supported versions of PostgreSQL are 9.4, 9.5 and 9.6.

Quick start

Requirements

pgrepup requires both a source and a destination PostgreSQL cluster.

The clusters can have been installed into the same server or on different hosts.

pgrepup doesn’t need to be installed on the clusters’ server.
It can be safely executed from a remote host that can access both pgsql clusters. In this case, it’s recommended that SSL is enabled in pg_hba.conf of both clusters because pgsql credentials are sent over the network.

Installation

pip install pgrepup

All versions of Python >= 2.7 are supported.

Replication

A pgsql cluster can be replicated and upgraded using pgrepup following these four steps:

  1. pgrepup config
     : a simple wizard asks the basic configuration parameters needed by pgrepup
    • Source and Destination database cluster
    • Directory where to store temporary files
  2. pgrepup check
     : various checks are performed both in Source and Destination cluster
    • if a check fails, pgrepup outputs a hint for helping you to configure each cluster
  3. pgrepup setup
     : if the checks are all ok, this setup installs and configure pglogical in both pgsql clusters
  4. pgrepup start
     : start the replication process

After the start command, you can monitor the replication process using the command 

pgrepup status

The output of the status command displays an entry for each database of the source cluster along with the status reported by pglogical extension.
The status can be one of the following three values:

  • initializing
     : pglogical is copying data from source to destination cluster
  • replicating
    : pglogical is using pgsql logical replication to replicate and upgrade new data changed into the source cluster
  • down
    : replication is down, check the PostgreSQL log in both clusters

After issuing the start command all databases will be in the 

initializing
 status. During this phase pglogical background workers are executing the SQL dump of the source cluster, so it can take a while to complete.
When the dump is completed, each database status will change to 
replicating
 as the data is progressively copied from the source cluster.

Upgrade

When the replication is working fine, you can switch your application to the destination cluster at any moment.
Just follow these steps:

  • stop your application connecting to the source cluster
  • ensure no more connections are made to the source cluster
  • stop replication using 
    pgrepup stop
      command
  • change the DSN in your application (or in your connection pooler) and point to the destination cluster
  • start your application
  • upgrade done! 🙂

Caveats and limits

pgrepup is still experimental. Please feel free to open an issue on github if you encounter problems.

DDL commands

DDL commands issued in a source cluster database are not replicated to the destination cluster. This is a limit of how pgsql logical replication works.
Use the 

pglogical.replicate_ddl_command
  SQL function on the source database in order to replicate the DDL on the destination cluster.

Be aware that, at the moment, pgrepup doesn’t handle the automatic subscription of newly created tables added using 

pglogical.replicate_ddl_command
 .
The recommended procedure is to re-start the replication process using the stop, setup and start commands.

A solution is in the works and will be available in the next release of pgrepup.

Sequences

Sequences are replicated between source and destination cluster. When the stop command is given, pgrepup uses pglogical function to do a final synchronization of each sequence value.
The pglogical function adds an artificial +1000 value to the actual sequence value: see this discussion on pglogical mailing list on google groups.

High number of databases

After issuing a start command, pglogical background workers start all simultaneously to dump the data of the source database into the destination database.

This can generate very high cpu/disk load on both clusters depending on the number of databases to replicate.

A feature that enables to limit the number of databases that are dumped concurrently is in the works.

Contributions

pgrepup is licensed using GPL-3 license. Source code is available at project page on github: https://github.com/rtshome/pgrepup

Contributions are welcome!

venerdì, 25 novembre

11:39

PgDay.IT 2016: partner! [:: Luca Ferrari ::]

Ormai vicinissimo il PgDay.IT 2016 si arricchisce di diversi partner, e speriamo che presto altri allunghino la lista. Al momento si ha:

Partner Platinum
  • Interlogica
  • Esosphera
  • Miriade

Partner Silver
  • 2ndQuadrant Italia

venerdì, 11 novembre

18:52

PgDay.IT 2016: programma online! [:: Luca Ferrari ::]

Il programma del prossimo (e ormai vicinissimo) PgDay.IT 2016 (decima edizione) è online. Anche se potrebbe subire qualche variazione da parte degli organizzatori, il programma online rende l'idea dei talk e degli aspetti che saranno trattati nel prossimo evento.

E se si vuole cogliere l'occasione per farsi un po' di pubblicità attraverso il PgDay.IT 2016 perché non diventare sponsor?

18:42

PgDay.IT 2016: schedule is online! [:: Luca Ferrari ::]

The PgDay.IT 2016 is approaching and the schedule is available on line here. Of course it could be subject to some little changes, but it is pretty mich a complete list of what you are going to see at the tenth edition of the PostgreSQL Italian Day.

giovedì, 10 novembre

21:50

Interessante spiegazione di vacuum e autovacuum [:: Luca Ferrari ::]

Sembra quasi un argomento da novellino: PostgreSQL deve usare la procedura di vacuum per mantenere la struttura dati (su disco) pulita e ordinata, in altre parole efficiente.
La necessità di vacuum è dovuta all'implementazione del sistema MVCC, non proprietario di PostgreSQL e usato anche in altri RDBMS. Spesso si accusa vacuum di essere uno degli svantaggi di PostgreSQL, senza considerare i vantaggi di MVCC.
Consiglio caldamente la lettura di questo articolo, ben strutturato, che dettaglia la necessità di vacuum nonché come ottimizzare il demone di autovacuum al fine di mantenere buone prestazioni anche in un database di grosse dimensioni.




giovedì, 20 ottobre

16:42

2ndQuadrant alla conferenza OpsCon – Edizione 2016 [2ndQuadrant]

Venerdì 28 ottobre a Firenze si svolgerà l’OpsCon, la conferenza europea su Open Infrastructure.

opscon

OpsCon è una conferenza organizzata dall’Associazione Culturale Inventati. Un team composto da da professionisti con esperienze molto diverse, uniti dalla stessa passione per l’IT.

OpsCon è una conferenza rivolta al mondo dei Data Center e Sysadmin. Gli argomenti trattati sono rivolti ad un pubblico di Manager, Amministratori di sistema, SRE, CIO / CTO, Architetti di sistema, etc.

L’evento si svolgerà presso il Grand Hotel Mediterraneo (in Lungarno del Tempio, 44 – 50121 Florence) e sono previsti oltre 300 partecipanti.

Il programma della conferenza si divide in due track e presenta un alto profilo di relatori a partire dal Keynote “Security” di Igor Falcomatà e si parlerà di:

  • Security / penetration test
  • IT company culture
  • Data center governance
  • Docker / openstack operations
  • Application lifecycle management
  • Agile devops / chatops
  • Webscraping / webharvesting

Il nostro Gabriele Bartolini presenterà, alle 14:30, “Impatto della strategia distribuita attraverso la cultura devops”. Un’esperienza diretta, rappresentativa di un ambiente di lavoro collaborativo in cui l’iniziativa, la pratica ed i fallimenti sono considerati la giusta via per il miglioramento continuo.

Ci vediamo a Firenze il 28 ottobre prossimo, vi aspettiamo!

OpsCon: quando Open significa interoperabilità, trasparenza, scalabilità e affidabilità.

11:49

PostgreSQL 9.6 “sbarca” a Milano! [2ndQuadrant]

Il 27 ottobre si svolgerà a Milano un evento dedicato alle novità presenti nella release 9.6 di PostgreSQL rilasciata il 29 settembre scorso.

postgres9-6-milano

L’evento è organizzato dal team italiano di 2ndQuadrant ed è rivolto a tutti gli appassionati di PostgreSQL, ai curiosi ed ai pochi titubanti che ancora non lo hanno adottato.

Il team di 2ndQuadrant, in continua espansione, ha mostrato la sua forte dedizione al progetto, contribuendo fortemente al rilascio di questa nuova ed importante release.

Affronteremo anche altre tematiche, come, ad esempio, l’importanza della corretta architettura a garanzia della business continuity.

L’incontro è gratuito e si svolgerà presso una sede di eccellenza: IBM Client Center.

Se qualcuno si domandasse il perché della sede, forse non ha letto di una importante novità presente nel repository di PostgreSQL per i pacchetti Debian e Ubuntu, disponibili su apt.postgresql.org.

Il 30 settembre è stato pubblicato l’annuncio ufficiale: il repository è stato esteso, rendendo disponibili i pacchetti precompilati per architettura POWER8 Little Endian di IBM.

Questo uno dei motivi per cui abbiamo scelto l’IBM Client Center, oltre al fatto che è nata una collaborazione tra 2ndQuadrant Italia, IBM Italia e IBM Power Systems Linux Center – Montpellier basata sull’intento di fornire a PostgreSQL grossi vantaggi aggiuntivi, magari attraverso l’attivazione di nuovi progetti condivisi.

Come è nostro costume abbiamo anche pensato al momento di networking, con il pranzo a chiusura della mattinata, riservando ampio spazio al libero confronto.

Per partecipare basta iscriversi attraverso Eventbrite. Ci aspettiamo un’ampia partecipazione per dare il benvenuto tutti insieme alla release 9.6 di PostgreSQL: Il database relazionale open source più avanzato.

Vi aspettiamo!

lunedì, 17 ottobre

12:25

Ritorno al futuro con PostgreSQL, parte 3: Come usare pg_rewind con PostgreSQL 9.6 [2ndQuadrant]

backtothefuture_03

Questa è la terza ed ultima parte dell’articolo dedicato a pg_rewind. Negli ultimi due abbiamo visto come pg_rewind può essere utile per correggere uno "split-brain" causato erroneamente durante la procedura di scambio dei ruoli tra un master ed uno standby, evitando di dover risincronizzare i nodi tramite un nuovo base backup. Abbiamo anche visto che questo è possibile per cluster di replica semplici che non coinvolgono più di due standby. In questo caso solo due nodi possono essere allineati dopo lo switchover, mentre gli altri necessitano di essere risincronizzati con un base backup. Dalla versione 9.6 di PostgreSQL, adesso è possibile utilizzare pg_rewind su cluster di replica più complessi.

A partire da PostgreSQL 9.6, pg_rewind ha una nuova funzionalità che gli permette di estendere l’orizzonte di visibilità della timeline di un intero cluster di alta disponibilità (HA), come quello di esempio nel mio precedente articolo. Adesso è infatti in grado di individuare il punto più recente nella timeline condiviso tra due o più nodi e risincronizzarli (e non più solo dall’ultimo checkpoint eseguito sul master prima della promozione dello standby, come nella versione 9.5).

Consideriamo quindi lo stesso esempio, ma adesso basato su PostgreSQL 9.6:

~$ # Set PATH variable
~$ export PATH=/usr/pgsql-9.6/bin:${PATH}
~$ 
~$ # This is the directory where we will be working on
~$ # Feel free to change it and the rest of the script
~$ # will adapt itself
~$ WORKDIR=/var/lib/pgsql/9.6
~$ 
~$ # Environment variables for PGDATA and archive directories
~$ MASTER_PGDATA=${WORKDIR}/master
~$ STANDBY1_PGDATA=${WORKDIR}/standby1
~$ STANDBY2_PGDATA=${WORKDIR}/standby2
~$ ARCHIVE_DIR=${WORKDIR}/archive
~$ 
~$ # Create the archive directory
~$ mkdir -p ${ARCHIVE_DIR}
~$ 
~$ # Create the HA cluster
~$ initdb --data-checksums -D ${WORKDIR}/master
~$ cat >> ${MASTER_PGDATA}/postgresql.conf <<EOF
~$ archive_command = 'cp %p ${ARCHIVE_DIR}/%f'
~$ archive_mode = on
~$ wal_level = hot_standby
~$ max_wal_senders = 10
~$ min_wal_size = '32MB'
~$ max_wal_size = '32MB'
~$ hot_standby = on
~$ wal_log_hints = on
~$ EOF
~$ cat >> ${MASTER_PGDATA}/pg_hba.conf <<EOF
~$ # Trust local access for replication
~$ # BE CAREFUL WHEN DOING THIS IN PRODUCTION
~$ local replication replication trust
~$ EOF
~$ pg_ctl -D /var/lib/pgsql/9.6/master -l ${WORKDIR}/master.log start
~$ psql -c "CREATE USER replication WITH replication"
~$ pg_basebackup -D ${STANDBY1_PGDATA} -R -c fast -U replication -x
~$ echo "port = 5433" >> ${STANDBY1_PGDATA}/postgresql.conf
~$ pg_ctl -D ${STANDBY1_PGDATA} -l ${WORKDIR}/standby.log start
~$ pg_basebackup -D ${STANDBY2_PGDATA} -R -c fast -U replication -x
~$ echo "port = 5434" >> ${STANDBY2_PGDATA}/postgresql.conf
~$ pg_ctl -D ${STANDBY2_PGDATA} -l ${WORKDIR}/standby2.log start

Simuliamo una promozione non voluta di uno dei due standby come nuovo master, lasciando gli altri nodi a formare un cluster HA indipendente:

~$ pg_ctl -D ${STANDBY1_PGDATA} promote

Adesso lo standby promosso procede nella timeline 2, mentre gli altri continuano sulla 1.

Completiamo lo "split-brain" creando una nuova tabella sul master che ha ancora in replica il secondo standby, e che non sarà visibile sul nodo appena promosso.

L’obiettivo adesso è quello di ricreare il cluster HA originale, con un master allineato alla situazione precedente lo "split-brain" (ovviamente senza la nuova tabella), che replichi due standby.

Dal momento che pg_rewind, con PostgreSQL 9.6, permette di rendere ogni nodo un master nel cluster HA, l’idea è di:

  1. Fermare gli standby (incluso quello promosso)
  2. Fermare il vecchio master e risincronizzarlo con lo standby promosso tramite pg_rewind
  3. Modificare i parametri port e primary_conninfo nella configurazione (del vecchio master), in modo da seguire lo standby promosso
  4. Risincronizzare l’altro standby con quello promosso usando pg_rewind
  5. Modificarne poi i parametri port e primary_conninfo nella configurazione, in modo da seguire lo standby promosso a nuovo master del cluster HA

Vediamo come:

~$ pg_ctl -D ${STANDBY2_PGDATA} stop
waiting for server to shut down.... done
server stopped
~$ pg_ctl -D ${MASTER_PGDATA} stop
waiting for server to shut down.... done
server stopped
~$ pg_rewind --target-pgdata=${MASTER_PGDATA} --source-server="port=5433 user=postgres dbname=postgres"
servers diverged at WAL position 0/A0002C8 on timeline 1
rewinding from last common checkpoint at 0/A000220 on timeline 1
Done!
~$ pg_rewind --target-pgdata=${STANDBY2_PGDATA} --source-server="port=5433 user=postgres dbname=postgres"
servers diverged at WAL position 0/A0002C8 on timeline 1
rewinding from last common checkpoint at 0/A000220 on timeline 1
Done!

Una volta cambiate le configurazioni del vecchio master e dell’altro standby non promosso, riavviarli:

~$ pg_ctl -D ${MASTER_PGDATA} start
~$ pg_ctl -D ${STANDBY2_PGDATA} start

Adesso tutti e tre i nodi sono attivi e:

  • Esiste un solo master in replica due standby, come all’inizio
  • La tabella creata non è visibile, quindi i dati sono consistenti con la situazione iniziale

Ottimo!! Pensate se avessimo dovuto risincronizzare due nodi utilizzando un backup completo… :S

Conclusioni

pg_rewind è uno degli strumenti più utili in ambito HA: permette di evitare la risincronizzazione tramite l’esecuzione di nuovi base backup, in caso di "split-brain" accidentali. PostgreSQL 9.6 aggiunge nuove e potenti funzionalità a pg_rewind, e permette nel caso di cluster HA complessi di ricreare lo stato originale a seguito di split-brain accidentali, partendo da qualsiasi nodo nel cluster per la resincronizzazione.

Come raccomandazione finale: prendete cura dell’archiviazione dei WAL! Generalmente, con la replica fisica, gli amministratori di database basano la loro architettura in contesto alta disponibilità solo sulla connessione streaming. Per poter usare pg_rewind è necessario aver configurata l’archiviazione dei WAL, in modo da poterli prelevare in caso non siano più presenti sul master. Vi consiglio di considerare l’utilizzo di Barman, e la sua funzionalità get-wal, per facilitare la gestione degli archivi e l’eventuale recupero dei WAl necessari.

venerdì, 14 ottobre

21:40

PGDay.IT 2016: CFP estesa ancora di qualche giorno [:: Luca Ferrari ::]

Al fine di fornire un PGDay.IT 2016 denso e ricco di contenuti gli organizzatori hanno deciso di estendere la Call For Papers di ancora qualche giorno, e precisamente fino a 

SABATO 22 OTTOBRE alle ore 23:59

Le informazioni su come inviare un contributo si trovano sul sito ufficiale della conferenza.

venerdì, 07 ottobre

11:28

Più “potenza” per PostgreSQL [2ndQuadrant]

L’annuncio ufficiale è stato pubblicato venerdì scorso: il repository di PostgreSQL per i pacchetti Debian e Ubuntu, apt.postgresql.org, è stato esteso, rendendo disponibili i pacchetti precompilati per architettura POWER8 Little Endian di IBM. power8-ok

Fantastico, non vi pare?

Quello che pochi sanno è come siamo arrivati ad ottenere questo risultato.

Ingrediente primario: le relazioni umane.

Tutto nasce ad ottobre 2014, durante la conferenza Open Source organizzata da Soiel a Milano. IBM Italia era come noi sponsor del convegno ed i nostri desk erano alquanto vicini.

I talk presentati da ambo le parti hanno dato lo spunto alle prime interazioni, ad un dialogo aperto nel rispetto reciproco.

L’approccio iniziale si è basato su una consapevolezza comune di un mercato IT in continua evoluzione, sempre più orientato verso l’Open Source, dove la crescente richiesta delle aziende è basata sull’affidabilità e sul supporto sia in termini di tecnologie che in termini di piattaforme.

Come i più sanno, IBM ha progettato un’architettura basata su tecnologia open che garantisce performance e sicurezza: IBM Power Systems. Una piattaforma dedicata alle tecnologie Open Source, e, di conseguenza, interessante per PostgreSQL.

Quindi: perché non permettere a PostgreSQL di sfruttare al massimo le prestazioni, la velocità e la potenza che una piattaforma come il Power8 mette a disposizione?

Inizialmente si trattò di effettuare dei test di performance sia della release 9.4 che della release 9.5 di PostgreSQL. Era aprile 2015. Questa fu l’occasione per noi di interagire con i tecnici presenti a Montpellier nell’IBM Power Systems Linux Center.

Il risultato dei  benchmarking fu presentato alla conferenza “5432…MeetUs! – Edizione 2015” proprio da uno dei tecnici di Montpellier, con il quale avevamo potuto interagire fino a quel momento solo da remoto. Un incontro fondamentale, durante il quale nasce l’idea di incrementare il repository di PostgreSQL con i pacchetti Debian e Ubuntu per Power.

Per renderlo fattibile, dovevano essere intraprese delle azioni da entrambe le parte, che richiedevano un’analisi di fattibilità ed una programmazione che non avrebbe portato azioni nell’immediato.

È stato proprio durante l’edizione 2016 della conferenza da noi organizzata “5432…MeetUs!” che sono state gettate le basi solide per lo sviluppo dei pacchetti, oggi disponibili per tutti.

La presenza non solo di IBM Italia, ma anche dei tecnici dell’IBM Power Systems Linux Center di Montpellier, ha concretizzato il progetto, portandolo ad un livello decisamente operativo. Marco Nenciarini, Debian developer e maintainer dei pacchetti distribuiti dalla Comunità di PostgreSQL, afferma: “È stato un piacere per me poter lavorare su un’architettura simile, progettata per carichi che richiedono concorrenza elevata e un’ampia banda di elaborazione dati” – “Poter collaborare con Sébastien Chabrolles di IBM Power Systems Linux Center – Montpellier – è stata un’esperienza fantastica che ha arricchito entrambi.”

Un grazie va anche a credativ, nella fattispecie Christoph Berg, che, nelle ultime settimane, ha collaborato con noi alla messa a punto dell’infrastruttura della Comunità di PostgreSQL per la creazione, il testing e la distribuzione dei pacchetti Debian e Ubuntu su architettura Power.

Per chiudere un grazie a IBM Italia, importante nella realizzazione del progetto, per la sua disponibilità e per averci permesso di incontrare persone fantastiche. Noi tutti in 2ndQuadrant siamo certi che questa collaborazione porterà altri fantastici tasselli alla crescita di PostgreSQL in ambito enterprise.

Da parte nostra, non vediamo l’ora di dare vita a nuovi progetti con IBM Italia e IBM Power Systems Linux Center – Montpellier.
A presto!

mercoledì, 28 settembre

12:19

Ritorno al futuro con PostgreSQL, parte 2: Come usare pg_rewind [2ndQuadrant]

backtothefuture_02

Nell’articolo precedente abbiamo visto come funziona pg_rewind per riallineare le timeline di un cluster di replica semplice composto da un master che replica su di un singolo standby. In un tale contesto, in un eventuale switchover, solo due nodi sono chiamati in causa. Ma cosa succede quando iniziano ad esserci diversi nodi di standby, anche in cascata?

Consideriamo adesso un cluster di replica un po’ più complesso, ma sempre basato su PostgreSQL 9.5, nel quale ci sono due standby non in cascata; in modo simile a quanto già fatto nel mio primo articolo dedicato a pg_rewind, creiamo questo cluster. Iniziamo col master:

# Set PATH variable
export PATH=/usr/pgsql-9.5/bin:${PATH}

# This is the directory where we will be working on
# Feel free to change it and the rest of the script
# will adapt itself
WORKDIR=/var/lib/pgsql/9.5

# Environment variables for PGDATA and archive directories
MASTER_PGDATA=${WORKDIR}/master
STANDBY1_PGDATA=${WORKDIR}/standby1
STANDBY2_PGDATA=${WORKDIR}/standby2
ARCHIVE_DIR=${WORKDIR}/archive

# Initialise the cluster
initdb --data-checksums -D ${MASTER_PGDATA}

# Basic configuration of PostgreSQL
cat >> ${MASTER_PGDATA}/postgresql.conf <<EOF
archive_command = 'cp %p ${ARCHIVE_DIR}/%f'
archive_mode = on
wal_level = hot_standby
max_wal_senders = 10
min_wal_size = '32MB'
max_wal_size = '32MB'
hot_standby = on
wal_log_hints = on
EOF

cat >> ${MASTER_PGDATA}/pg_hba.conf <<EOF
# Trust local access for replication
# BE CAREFUL WHEN DOING THIS IN PRODUCTION
local replication replication trust
EOF

# Create the archive directory
mkdir -p ${ARCHIVE_DIR}

# Start the master
pg_ctl -D ${MASTER_PGDATA} -l ${WORKDIR}/master.log start

# Create the replication user
psql -c "CREATE USER replication WITH replication"

E procediamo poi con il primo standby:

# Create the first standby
pg_basebackup -D ${STANDBY1_PGDATA} -R -c fast -U replication -x

cat >> ${STANDBY1_PGDATA}/postgresql.conf <<EOF
port = 5433
EOF

# Start the first standby
pg_ctl -D ${STANDBY1_PGDATA} -l ${WORKDIR}/standby1.log start

In modo identico, creiamo il secondo standby:

# Create the second standby
pg_basebackup -D ${STANDBY2_PGDATA} -R -c fast -U replication -x

cat >> ${STANDBY2_PGDATA}/postgresql.conf <<EOF
port = 5434
EOF

# Start the second standby
pg_ctl -D ${STANDBY2_PGDATA} -l ${WORKDIR}/standby2.log start

Consideriamo anche in questo caso che siano mantenuti pochi WAL sul master (notare come è stato valorizzato il parametro max_wal_size) che vengono opportunamente archiviati.

Se inseriamo un po’ di dati sul master, li vedremo visibili anche su entrambi gli (hot) standby.

Promuoviamo adesso uno dei due standby a nuovo master (ad esempio, quello basato su ${STANDBY1_PGDATA}), lasciando gli altri nodi inalterati:

pg_ctl -D ${STANDBY1_PGDATA} promote

Le modifiche eventualmente apportate al precedente master non saranno visibili sullo standby promosso, mentra saranno visibili sull’altro; nella directory archive/ è possibile trovare il file 00000002.history, che mostra un cambio nella timeline avvenuto durante la promozione, come visto anche nel precedente caso.

Tentiamo adesso di correggere l’errore, ricreando il cluster di replica come in origine, con lo standby promosso come nuovo master e gli altri due nodi come rispettivi standby: la procedurà che cercherò di seguire sarà

  1. spengere il vecchio master e risincronizzarlo a partire dallo standby promosso usando pg_rewind
  2. spengere il secondo standby e risincronizzarlo a partire dallo standby promosso, come fatto nel punto precedente

Iniziamo col primo punto:

~$ pg_ctl -D ${MASTER_PGDATA} stop
waiting for server to shut down.... done
server stopped
~$ pg_rewind --target-pgdata=${MASTER_PGDATA} \
    --source-server="port=5433 user=postgres dbname=postgres"
servers diverged at WAL position 0/501E680 on timeline 1
could not open file "/var/lib/pgsql/9.5/master/pg_xlog/000000010000000000000005": No such file or directory

could not find previous WAL record at 0/501E680
Failure, exiting

Come ci aspettavamo, mancano i WAL! Sì, so di essere ripetitivo, ma come già detto è sempre buona norma archiviare i WAL! Infatti, adesso è possibile recuperare i WAL mancanti: qui la procedurà sarà quella di copiarli manualmente per poi inserirli all’interno della pg_xlog/ del master, per poi rilanciare nuovamente pg_rewind (ma considerate anche l’uso di Barman per questo):

~$ cp ${ARCHIVE_DIR}/00000001000000000000000[56] ${MASTER_PGDATA}/pg_xlog/
~$ pg_rewind --target-pgdata=${MASTER_PGDATA} \
    --source-server="port=5433 user=postgres dbname=postgres"
servers diverged at WAL position 0/501E680 on timeline 1
rewinding from last common checkpoint at 0/501E5D8 on timeline 1
Done!

Ricordiamoci di cambiare opportunamente il parametro primary_conninfo all’interno del file recovery.conf ed il parametro port nel postgresql.conf, ed il vecchio master è ora pronto per seguire lo standby promosso. Facciamo adesso lo stesso anche col secondo standby:

~$ pg_ctl -D ${STANDBY2_PGDATA} stop
waiting for server to shut down.... done
server stopped
~$ pg_rewind --target-pgdata=${STANDBY2_PGDATA} \
    --source-server="port=5433 user=postgres dbname=postgres"
could not find common ancestor of the source and target cluster's timelines
Failure, exiting

Dunque, in questo caso non funziona: il secondo standby deve essere comunque risincronizzato dallo standby promosso tramite un nuovo base backup…

Conclusioni

pg_rewind è molto utile per risincronizzare i nodi tra di loro in un cluster di replica. Tuttavia, per infrastrutture che prevedono più standby non è possibile risincronizzare ogni nodo con solo questo tool.

Nonostante questo l’eventuale downtime degli standby è ridotto: un nodo può essere comunque velocemente riallineato, nell’attesa che gli altri vengano poi man mano aggiunti con nuovi base backup.

PostgreSQL 9.6 introduce una nuova, interessante funzionalità per pg_rewind: il suo orizzonte di visibilità può essere esteso e sarà sempre possibile trovare un punto comune nella timeline di un cluster di replica… non perdere la terza e ultima parte, dedicata alle novità di pg_rewind presenti in PostgreSQL 9.6!

domenica, 18 settembre

18:42

PGDay.IT 2016: Call For Papers [:: Luca Ferrari ::]

Ve ne sarete ovviamente già accorti, perché è da circa una settimana, che la Call For Papers per il PGDay.IT 2016 è aperta.
C'è tempo fino a MARTEDi' 11 OTTOBRE (ore 23:59).
Cosa bisgona fare? Vincere la timidezza e inviare il proprio contributo per talk/tutorial seguendo le istruzioni riportate qui. Ogni singolo contributo è importante e verrà valutato attentamente al fine di garantire un grandioso programma della decima edizione della conferenza.

18:42

PGDay.IT 2016: it's time for you to speak! [:: Luca Ferrari ::]

As you probably already know the Call For Papers for the PGDay.IT 2016 is now open. Please see the details here and send your contribution following the instructions. The organizing committee will review each proposal in order to deliver a great program for the tenth edition of the italian PostgreSQL based conference.

lunedì, 12 settembre

11:00

Ritorno al Futuro con PostgreSQL, parte 1: Introduzione a pg_rewind [2ndQuadrant]

backtothefuture_01

PostgreSQL 9.5 introduce pg_rewind, un tool per risincronizzare un vecchio master con uno standby promosso che funziona anche se nel frattempo, non volutamente, quest’ultimo ha proseguito nella sua timeline. Questo è il caso, ad esempio, di uno switchover non eseguito con successo.

Avete mai concluso uno switchover con uno “split brain”? Questa situazione succede quando invece che aver invertito i ruoli tra master e standby, ottenete due master ciascuno con la sua propria timeline. È in situazioni come queste che pg_rewind viene in aiuto dei DBA PostgreSQL che si devono confrontare con i problemi di alta disponibilità (HA).

Fino alla versione 9.5 di PostgreSQL c’era una sola soluzione possibile: risincronizzare la PGDATA del vecchio master con un nuovo base backup a partire dallo standby promosso e poi aggiungerlo come nuovo standby al cluster di replica. Questo diventa un problema quando le dimensioni del database sono notevoli: nel caso di diverse centinaia di GB non è semplice effettuare queste operazioni mantenendo allo stesso tempo downtime ridotti.

Riportare un database allo stato in cui si trovava in un determinato momento del passato può essere complicato, ma nonostante questo ci sono varie strategie. Suggerisco a chi è interessato di dare un’occhiata agli articoli di Gulcin che affrontano il tema in PostgreSQL e che menziona anche l’uso di pg_rewind.

Come funziona pg_rewind

pg_rewind è in grado di leggere tutti i file contenuti nella PGDATA del vecchio master, identificare i blocchi modificati durante un eventuale cambio di timeline e quindi copiare solo questi dallo standby promosso, in modo da riallinearsi. Come “effetto collaterale”, anche i file di configurazione vengono copiati e sovrascritti, quindi è compito del DBA quello di riadattarli eventualmente al nodo in esame. Ad ogni modo, questo evita di dover risincronizzare totalmente la PGDATA.

Per fare questo, è necessario avere tutti i WAL prodotti negli ultimi istanti di vita del vecchio master precedenti lo switchover. Le modifiche sono individuate dal confronto tra i blocchi di dati presenti nella PGDATA con le modifiche inserite nei WAL. Una volta identificati i blocchi modificati, vengono sostituiti con quelli presenti nello standby promosso, mimando una sorta di “rewind” della timeline.

Inoltre:

  • le istanze debbono essere state inizializzate con l’opzione “-k” (o --data-checksums)
  • il parametro wal_log_hints deve essere abilitato

Fino a PostgreSQL 9.5, i WAL necessari sono quelli a partire dall’ultimo checkpoint, dato che pg_rewind non è in grado di andare indietro nella timeline ulteriormente.

Per capire meglio come funziona, consideriamo questo semplice esempio:

# Set PATH variable
export PATH=/usr/pgsql-9.5/bin:${PATH}

# This is the directory where we will be working on
# Feel free to change it and the rest of the script
# will adapt itself
WORKDIR=/var/lib/pgsql/9.5

# Environment variables for PGDATA and archive directories
MASTER_PGDATA=${WORKDIR}/master
STANDBY1_PGDATA=${WORKDIR}/standby1
ARCHIVE_DIR=${WORKDIR}/archive

# Initialise the cluster
initdb --data-checksums -D ${MASTER_PGDATA}

# Basic configuration of PostgreSQL
cat >> ${MASTER_PGDATA}/postgresql.conf <<EOF
archive_command = 'cp %p ${ARCHIVE_DIR}/%f'
archive_mode = on
wal_level = hot_standby
max_wal_senders = 10
min_wal_size = '32MB'
max_wal_size = '32MB'
hot_standby = on
wal_log_hints = on
EOF

cat >> ${MASTER_PGDATA}/pg_hba.conf <<EOF
# Trust local access for replication
# BE CAREFUL WHEN DOING THIS IN PRODUCTION
local replication replication trust
EOF

# Create the archive directory
mkdir -p ${ARCHIVE_DIR}

# Start the master
pg_ctl -D ${MASTER_PGDATA} -l ${WORKDIR}/master.log start

# Create the replication user
psql -c "CREATE USER replication WITH replication"

(notare il basso numero di WAL mantenuti volutamente nel master), ed uno standby:

# Create the first standby
pg_basebackup -D ${STANDBY1_PGDATA} -R -c fast -U replication -x

cat >> ${STANDBY1_PGDATA}/postgresql.conf <<EOF
port = 5433
EOF

# Start the first standby
pg_ctl -D ${STANDBY1_PGDATA} -l ${WORKDIR}/standby1.log start

Inseriamo alcuni dati sul master: questi saranno visibili anche dallo (hot) standby.

Promuoviamo adesso lo standby, lasciando inalterato il master:

pg_ctl -D ${STANDBY1_PGDATA} promote

Se adesso aggiorniamo il master i cambiamenti non saranno più visibili dallo standby. Inoltre, nella directory archive/ è presente il file 00000002.history e questo mostra che c’è stato un cambio di timeline durante la promozione.

Proviamo adesso ad effettuare il “rewind” del master, e ad aggiungerlo in replica allo standby promosso:

~$ pg_ctl -D ${MASTER_PGDATA} stop
waiting for server to shut down.... done
server stopped
~$ pg_rewind --target-pgdata=${MASTER_PGDATA} \
    --source-server="port=5433 user=postgres dbname=postgres"

Va notato che per la connessione al server sorgente – lo standby promosso – è stato usato l’utente postgres perché pg_rewind necessita di una connessione tramite superuser per ispezionare i blocchi di dati.

Se il parametro max_wal_size non è sufficientemente alto per mantenere nella pg_xlog/ del (vecchio) master i WAL necessari, come volutamente configurato nel nostro esempio, viene emesso un errore come il seguente:

The servers diverged at WAL position 0/3015938 on timeline 1.
could not open file "/var/lib/pgsql/9.5/master/pg_xlog/000000010000000000000002": No such file or directory

could not find previous WAL record at 0/3015938
Failure, exiting

Ci sono due possibili soluzioni a questo:

  • copiare manualmente i WAL mancanti dall’archivio alla directory pg_xlog/ del master, a partire da quello riportato nel messaggio di errore
  • configurare opportunamente il parametro restore_command all’interno del file recovery.conf da includere nella PGDATA del (vecchio) master, così che pg_rewind troverà automaticamente i WAL mancanti.

La seconda è probabilmente la più adatta. Pensiamo, ad esempio, al caso in cui l’archivio di WAL è gestito tramite Barman: il restore_command potrebbe essere basato sulla funzionalità get-wal di Barman, come chiaramente spiegato in questo interessante articolo di Gabriele. Così facendo, Barman può essere usato come una possibile sorgente da cui prelevare i WAL necessari a pg_rewind.

Una volta che tutti i WAL necessari sono disponibili, pg_rewind può essere nuovamente eseguito, questa volta correttamente, ottenendo il seguente messaggio:

~$ pg_rewind --target-pgdata=${MASTER_PGDATA} \
    --source-server="port=5433 user=postgres dbname=postgres"
servers diverged at WAL position 0/3015938 on timeline 1
rewinding from last common checkpoint at 0/3000140 on timeline 1
Done!

Va ribadito che adesso verranno copiati solo pochi blocchi di dati della PGDATA, quelli modificati durante lo split-brain, anche se il database occupasse centinaia di GB! Ricordiamoci poi che anche le configurazioni sono state copiate e sovrascritte, incluso un eventuale recovery.conf già presente nella PGDATA del vecchio master che deve essere convertito in un nuovo standby. Quindi, **bisogna ricordarsi di*:

  • modificare la porta utilizzata dall’istanza (5432 nel nostro caso) nel postgresql.conf;
  • modificare la primary_conninfo nel recovery.conf in modo da assicurarsi che il vecchio master sia in grado di poter effettuare la connessione streaming verso lo standby promosso a nuovo master.

Una volta che questo è stato fatto, basta far partire nuovamente il vecchio master e questo sarà in grado di seguire in replica quello nuovo.

Avete cluster di replica più complessi di questo basato su due soli nodi? Non preoccupatevi! La seconda parte entrerà ancor più nel dettaglio nel funzionamento di pg_rewind in PostgreSQL 9.5!

venerdì, 09 settembre

18:36

E' ora di rimboccarsi le maniche: PGDay.IT X! [:: Luca Ferrari ::]

E' ufficiale: il PGDay.IT 2016 è in corso di organizzazione.
La dcima edizione della conferenza nazionale dedicata a PostgreSQL si svolgerà a Prato, nella splendida sede offerta dalla Camera di Commercio (sede già sfruttata l'anno precedente).
La data è il 13 Dicembre 2016.

pgday_468x60_it

Fra pochi giorni sarà disponibile la Call For Papers e gli organizzatori si metteranno al lavoro per selezionare gli interventi e offrire un programma degno di nota per questa edizione così importante nella storia di ITPUG e di PostgreSQL in Italia.

Per maggiori informazioni vedere il sito ufficiale 2016.pgday.it.

giovedì, 11 agosto

15:00

Rilascio aggiornamenti di sicurezza, 11 agosto 2016 [2ndQuadrant]

Il PGDG (PostgreSQL Global Development Group) ha rilasciato un aggiornamento per tutte le versioni del sistema di database PostgreSQL attualmente supportate, composto dalle “minor release” 9.5.4, 9.4.9, 9.3.14, 9.2.18 e 9.1.23.

L’aggiornamento risolve due problemi di sicurezza che causavano rispettivamente un crash del sistema e una escalation delle autorizzazioni. Inoltre corregge altri bug emersi negli ultimi tre mesi. Si incoraggiano gli utenti a pianificare l’aggiornamento dei server alla prima occasione possibile.

Aggiornamenti di sicurezza

Questo aggiornamento risolve due falle di sicurezza:

  • CVE-2016-5423: certain nested CASE expressions can cause the server to crash.
  • CVE-2016-5424: database and role names with embedded special characters can cause triggering code during administrative operations like pg_dumpall.

Il fix del secondo problema aggiunge anche una opzione, --reuse-previous, al comando \connect di psql. Dopo l’aggiornamento, pg_dumpall si rifiuterà di gestire nomi di ruolo e database contenenti un ritorno a capo. Per maggiori informazioni sui bug e sul loro impatto in termini di retro-compabilità, si faccia riferimento alle note di rilascio.

Altre correzioni e miglioramenti

Questo aggiornamento corregge anche un numero di bug emersi e riportati nei mesi precedenti. Alcuni di questi riguardano esclusivamente la 9.5, ma altri si riferiscono a tutte le versioni supportate. La lista di correzioni, in inglese, è la seguente:

  • Fix misbehaviors of IS NULL/IS NOT NULL with composite values
  • Fix three areas where INSERT … ON CONFLICT failed to work properly with other SQL features.
  • Make INET and CIDR data types properly reject bad IPv6 values
  • Prevent crash in close_ps() for NaN input coordinates
  • Avoid possible crash in pg_get_expr()
  • Fix several one-byte buffer over-reads in to_number()
  • Don’t pre-plan query if WITH NO DATA is specified
  • Avoid crash-unsafe state with expensive heap_update() paths
  • Fix hint bit update during WAL replay of row locking operations
  • Avoid unnecessary “could not serialize access” with FOR KEY SHARE
  • Avoid crash in postgres -C when the specified variable is a null string
  • Fix two issues with logical decoding and subtransactions
  • Ensure that backends see up-to-date statistics for shared catalogs
  • Avoid consuming a transaction ID during VACUUM
  • Prevent possible failure when vacuuming multixact IDs in an upgraded database
  • When a manual ANALYZE specifies colums, don’t reset changes_since_analyze
  • Fix ANALYZE’s overestimation of n_distinct for nulls
  • Fix bug in b-tree mark/restore processing
  • Fix building of large (bigger than shared_buffers) hash indexes
  • Prevent infinite loop in GiST index build with NaN values
  • Fix possible crash during a nearest-neighbor indexscan
  • Fix “PANIC: failed to add BRIN tuple” error
  • Prevent possible crash during background worker shutdown
  • Many fixes for issues in parallel pg_dump and pg_restore
  • Make pg_basebackup accept -Z 0 as no compression
  • Make regression tests safe for Danish and Welsh locales

La libreria client libpq è stata aggiornata per supportare il nuovo formato di versioning di PostgreSQL che sarà composto soltanto da due parti e non più tre come ora (e.g.: 10.0 invece di 9.5.4). Questo aggiornamento contiene anche la release 2016f di tzdata, con aggiornamenti per Kemerovo, Novosibirsk, Azerbaijan, Bielorussia e Marocco.

Uscita dal supporto comunitario per la versione 9.1

La versione 9.1 uscirà dal supporto comunitario a settembre 2016 (EOL, End-of-Life). Di conseguenza, questo aggiornamento sarà probabilmente l’ultimo per questa versione. Gli utenti di PostgreSQL 9.1 dovrebbero iniziare a pianificare un aggiornamento a una versione più recente prima di tale data. Si vedano le policy di versioning per maggiori informazioni sulle date di fine supporto comunitario delle varie versioni di PostgreSQL.

Istruzioni di aggiornamento

Come ogni aggiornamento di minor release, non è necessario eseguire alcun dump e restore dei database e neppure utilizzare pg_upgrade per effettuare questi ultimi aggiornamenti; è sufficiente spegnere il servizio PostgreSQL ed aggiornare i binari. Gli utenti che hanno saltato aggiornamenti precedenti, potrebbero necessitare di ulteriori operazioni da eseguire dopo l’aggiornamento; si vedano le varie note di rilascio per maggiori dettagli.

Link utili

lunedì, 11 luglio

09:25

PostgreSQL 9.6: sequential scan parallelo [2ndQuadrant]

Parallel-Sequential-Scan

Per lungo tempo una delle più note mancanze di PostgreSQL è stata la possibilità di parallelizzare le query. Con l’uscita della versione 9.6 non sarà più così. È stato infatti svolto un grande lavoro sul tema, per il quale il primo risultato è stato il commit 80558c1, in cui viene introdotta la parallelizzazione dei sequential scan in alcuni casi che vedremo nel corso di questo articolo.

Innanzitutto, una premessa: lo sviluppo di questa feature è stato continuo e alcuni parametri hanno cambiato nome nel susseguirsi di commit. L’articolo è stato scritto con un checkout al 17 giugno, e presenta alcune caratteristiche che saranno presenti solo dalla beta2 della 9.6.

Rispetto alla major 9.5 sono stati introdotti nuovi parametri all’interno della configurazione. Questi sono:

  • max_parallel_workers_per_gather: il numero di worker che possono assistere un sequential scan su una tabella;
  • min_parallel_relation_size: la dimensione minima che deve avere una relazione affinché il planner consideri l’uso di worker aggiuntivi;
  • parallel_setup_cost: parametro del planner che valuta il costo di istanziare un worker;
  • parallel_tuple_cost: parametro del planner che valuta il costo di trasferire una tupla da un worker a un altro;
  • force_parallel_mode: parametro utile per i test, forza il parallelismo anche su query su cui il planner agirebbe in altri modi.

Vediamo come i worker aggiuntivi possono essere usati per velocizzare le nostre query. Creiamo una tabella di test con un campo INT e cento milioni di record:

postgres=# CREATE TABLE test (i int);
CREATE TABLE
postgres=# INSERT INTO test SELECT generate_series(1,100000000);
INSERT 0 100000000
postgres=# ANALYSE test;
ANALYZE

Di default PostgreSQL ha max_parallel_workers_per_gather impostato a 2, per cui verranno attivati due worker durante un sequential scan.

Un semplice sequential scan non presenta novità alcuna:

postgres=# EXPLAIN ANALYSE SELECT * FROM test;
                                                       QUERY PLAN                                                       
------------------------------------------------------------------------------------------------------------------------
 Seq Scan on test  (cost=0.00..1442478.32 rows=100000032 width=4) (actual time=0.081..21051.918 rows=100000000 loops=1)
 Planning time: 0.077 ms
 Execution time: 28055.993 ms
(3 rows)

È infatti richiesta la presenza di una clausola WHERE per la parallelizzazione:

postgres=# EXPLAIN ANALYZE SELECT * FROM test WHERE i=1;
                                                       QUERY PLAN
------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=1000.00..964311.60 rows=1 width=4) (actual time=3.381..9799.942 rows=1 loops=1)
   Workers Planned: 2
   Workers Launched: 2
   ->  Parallel Seq Scan on test  (cost=0.00..963311.50 rows=0 width=4) (actual time=6525.595..9791.066 rows=0 loops=3)
         Filter: (i = 1)
         Rows Removed by Filter: 33333333
 Planning time: 0.130 ms
 Execution time: 9804.484 ms
(8 rows)

Possiamo tornare al comportamento precedente e osservarne le differenze impostando max_parallel_workers_per_gather a 0:

postgres=# SET max_parallel_workers_per_gather TO 0;
SET
postgres=# EXPLAIN ANALYZE SELECT * FROM test WHERE i=1;
                                               QUERY PLAN
--------------------------------------------------------------------------------------------------------
 Seq Scan on test  (cost=0.00..1692478.40 rows=1 width=4) (actual time=0.123..25003.221 rows=1 loops=1)
   Filter: (i = 1)
   Rows Removed by Filter: 99999999
 Planning time: 0.105 ms
 Execution time: 25003.263 ms
(5 rows)

Un tempo 2.5 volte maggiore.

Non sempre il planner considera un sequential scan parallelo la migliore opzione. Se la query non è abbastanza selettiva e ci sono molte tuple da trasferire, è possibile che sia preferito un sequential scan "classico":

postgres=# SET max_parallel_workers_per_gather TO 2;
SET
postgres=# EXPLAIN ANALYZE SELECT * FROM test WHERE i<90000000;
                                                      QUERY PLAN
----------------------------------------------------------------------------------------------------------------------
 Seq Scan on test  (cost=0.00..1692478.40 rows=90116088 width=4) (actual time=0.073..31410.276 rows=89999999 loops=1)
   Filter: (i < 90000000)
   Rows Removed by Filter: 10000001
 Planning time: 0.133 ms
 Execution time: 37939.401 ms
(5 rows)

Infatti, se proviamo a forzare un sequential scan parallelo, otteniamo un risultato peggiore:

postgres=# SET parallel_tuple_cost TO 0;
SET
postgres=# EXPLAIN ANALYZE SELECT * FROM test WHERE i<90000000;
                                                             QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=1000.00..964311.50 rows=90116088 width=4) (actual time=0.454..75546.078 rows=89999999 loops=1)
   Workers Planned: 2
   Workers Launched: 2
   ->  Parallel Seq Scan on test  (cost=0.00..1338795.20 rows=37548370 width=4) (actual time=0.088..20294.670 rows=30000000 loops=3)
         Filter: (i < 90000000)
         Rows Removed by Filter: 3333334
 Planning time: 0.128 ms
 Execution time: 83423.577 ms
(8 rows)

Possiamo incrementare il numero di worker fino a raggiungere max_worker_processes (default: 8). Ripristiniamo il valore di parallel_tuple_cost vediamo quello che accade aumentando max_parallel_workers_per_gather a 8.

postgres=# SET parallel_tuple_cost TO DEFAULT ;
SET
postgres=# SET max_parallel_workers_per_gather TO 8;
SET
postgres=# EXPLAIN ANALYZE SELECT * FROM test WHERE i=1;
                                                       QUERY PLAN
------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=1000.00..651811.50 rows=1 width=4) (actual time=3.684..8248.307 rows=1 loops=1)
   Workers Planned: 6
   Workers Launched: 6
   ->  Parallel Seq Scan on test  (cost=0.00..650811.40 rows=0 width=4) (actual time=7053.761..8231.174 rows=0 loops=7)
         Filter: (i = 1)
         Rows Removed by Filter: 14285714
 Planning time: 0.124 ms
 Execution time: 8250.461 ms
(8 rows)

Nonostante PostgreSQL potesse usare fino a 8 worker, ne ha instanziati solo 6. Questo perché Postgres ottimizza il numero di worker anche in base alle dimensioni della tabella e al parametro min_parallel_relation_size. Il numero dei worker messi a disposizione da postgres si basa su una successione geometrica di ragione 3 il cui primo termine è min_parallel_relation_size. Facciamo un esempio. Considerando gli 8MB del default del parametro:

Dimensione Worker
<8MB 0
<24MB 1
<72MB 2
<216MB 3
<648MB 4
<1944MB 5
<5822MB 6

Possiamo vedere che, essendo la nostra tabella 3458MB, 6 è il massimo numero di worker disponibili.

postgres=# \dt+ test
                    List of relations
 Schema | Name | Type  |  Owner   |  Size   | Description
--------+------+-------+----------+---------+-------------
 public | test | table | postgres | 3458 MB |
(1 row)

Per concludere, una breve dimostrazione dei miglioramenti ottenuti da attraverso questa patch. Lanciando la nostra query abilitando un numero crescente di worker, otteniamo i seguenti risultati:

Worker Tempo
0 24767.848 ms
1 14855.961 ms
2 10415.661 ms
3 8041.187 ms
4 8090.855 ms
5 8082.937 ms
6 8061.939 ms

Possiamo vedere che i tempi migliorano notevolmente, fino ad arrivare ad un terzo del valore iniziale. È semplice da spiegare anche il fatto che non ci siano miglioramenti fra l’uso di tre e 6 worker: la macchina su cui è stato eseguito il test ha 4 cpu disponibili, per cui dopo 3 worker più il processo originale i risultati si stabilizzano.

Per concludere, con la 9.6 PostgreSQL ha posto le basi per la parallelizzazione delle query, di cui il sequential scan parallelo è solo il primo, ottimo, risultato. Vedremo infatti come sempre nella 9.6 siano state parallelizzate anche le aggregazioni, ma questo è materiale per un altro articolo che uscirà nelle prossime settimane.

lunedì, 20 giugno

10:30

Backup concorrenti con Barman e PostgreSQL 9.6 [2ndQuadrant]

Postgres-9.6+b PostgreSQL 9.6 estende il framework disponibile per i backup fisici permettendo agli utenti di eseguire backup in modo concorrente. Barman supporterà questo nuovo set di funzioni in modo trasparente, senza più richiedere l’estensione pgespresso.

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!

lunedì, 23 maggio

11:00

Rilasciato Barman 1.6.1 [2ndQuadrant]

2ndQuadrant è orgogliosa di annunciare la release 1.6.1 di Barman, il tool per il Backup e la Recovery Manager di PostgreSQL.

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.

mercoledì, 20 aprile

18:49

pgAdmin 4 [:: Luca Ferrari ::]

C'è molto fermento ed eccitazione dopo l'annuncio che la versione 4 del famoso tool specifico per la gestione di un cluster PostgreSQL è vicina alla meta!
Come già anticipato un paio di anni fa, questa versione abbandona le wxWidget per lasciare spazio a Python e web frameworks, in modo da offrire maggiore flessibilità.
Con l'occasione gli autori hanno rivisto l'intera UI per migliorare l'esperienza di utilizzo del prodotto. Inutile dire che non vedo l'ora di provarlo!

lunedì, 11 aprile

21:38

Livelli di sicurezza in PostgreSQL [:: Luca Ferrari ::]

Può sembrare banale, ma Bruce Momjan ha pubblicato un corto e specifico post relativo ai livelli di sicurezza presenti in PostgreSQL, partendo dal rigetto delle connessioni al database fino alla sicurezza a livello di riga.
Consiglio a tutti la lettura.

sabato, 05 marzo

17:46

ITPUG @ Pycon sette [:: Luca Ferrari ::]

Grazie agli sforzi di alcuni soci volontari, una delegazione di ITPUG sarà in "missione" alla Pycon 7, la famosa e conosciuta conferenza italiana sul linguaggio di programmazione Python.

https://www.pycon.it/it/

Per il programma della conferenza vedere qui, mentre per i talk PostgreSQL cercare in particolare la track PyDatabase.

lunedì, 26 ottobre

21:49

ITPUGLab @ PGDay.IT 2015 [:: Luca Ferrari ::]

I had the opportunity and pleasure to play an active role in the third ITPUGLab, a well established tradition and a successful event me and my friend Gianluca proposed a few years ago.
And I have to say: it was really fun and educative.

What is the ITPUGLab? In short: it is an Open Space container entirely focused on PostgreSQL.
Attendees meet for exchanging, proposing or requesting ideas, thoughts, approaches and experiences getting 'hands-on' in a LAN environment and building a constructive shared experience on their laptops, or even philosophical discussions of any kind all being user-experience centric and related to PostgreSQl. No matter what the participants' skill level is.
There are no predefined contents: attendees come and propose or join others' proposals.
The evolution of the shared interactive contributions is what leads to discovering a path (not necessarily the right one) and get to a possible goal.
This translates to human-networking with a  PostgreSQL-social approach, allowing attendees to get acquainted in ways one cannot predict.

This year we had two and half hours dedicated to the lab, a very comfortable room and very nice people attending.

The following is the list of topics discussed end experienced:
  • installation on Microsoft Windows, where the users challenged the differences on installing PostgreSQL on a Unix-unlike machine, coming to the goal of providing a running instance to other people in the room;
  • migration and upgrade, with particular interest to the migration of a quite old cluster from a MS Windows machine to a mature and up-to-date cluster on a *nix machine, as well how to do it automatically and error-safely;
  • install, configure and use the PostGIS extension from scratch;
  • pl/pgsql scripting, with particular focus on editors, repos and best practices;
  • data integrity check and validation with regard to the database and/or application;
  • periodical data dump and load from one server to one (or many) others, with regard to various scenarios and possible automations.

Rules in the ITPUGLab are simple: after introducing themselves, participants start grouping spontaneously, warm up and get discussing, hands-on. Everybody can join a formed OpenSpace as well as leave it or, even, the room. When it's over, it's over: once the time elapsed pencil are down, and what happened is always the only and rightmost thing could happened.
Pictures cannot provide the excitement and fun filling the room.






As said, this is the third edition of the ITPUGLab, and quite frankly I'm proud of the continuous success it is getting within the PGDay.IT annual conference.
One thing all the three edition did have in common is the same request by attendees for more time: we are evaluating how to extend the session in the next PGDay.IT.
If you are coming to the next PGDay.IT, get into the lab: it's an experience you really don't want to miss!