Feeds

FeedRSSLast fetchedNext fetched after
2ndQuadrant XML 18:01, martedì, 28 marzo 19:01, martedì, 28 marzo
:: Luca Ferrari :: XML 18:01, martedì, 28 marzo 19:01, martedì, 28 marzo
Il blog di Enrico Pirozzi - Postgresql XML 18:01, martedì, 28 marzo 19:01, martedì, 28 marzo
Planet PostgreSQL – Denis Gasparin XML 18:01, martedì, 28 marzo 19:01, martedì, 28 marzo
PostgreSQL – Blog di Diego Cinelli XML 18:01, martedì, 28 marzo 19:01, martedì, 28 marzo

venerdì, 24 marzo

19:08

Caratteri, codifiche, ordinamento [:: Luca Ferrari ::]

Un articolo molto chiaro e sintetico che aiuta a tenere a mente i concetti dietro collation, charater encoding e charset.
Consiglio vivamente la lettura.

18:30

SpeakerFight & PGDay.IT: è possibile? [:: Luca Ferrari ::]

Sono venuto a conoscenza per caso di un progetto interessante: SpeakerFight.
L'idea è abbastanza semplice, e l'implementazione mantiene la semplicità: si inviano dei contributi di talk (per conferenze ed eventi) e si lascia che le persone li votino, in un meccanismo stile "star" ben noto da altre piattaforme. I talk/contributi che hanno ricevuto il maggior numero di voti vengono selezionati per l'evento.

Un paio di giorni fa ho proposto di valutare questo meccasnimo nell'ambito del PGDay.IT. Da tempo sono sostenitore di una call-for-papers piu' aperta e con selezione maggiormente trasparente rispetto a quanto è avvenuto nelle ultime edizioni. Anzi, a dire il vero ho anche proposto piu' volte di fare un "speaker fight" del poveraccio addirittura per il keynote, proponendo di chiedere alla community chi fosse interessato a fare un keynote speech invece che andare su singolo invito diretto.

Ora sistemi come quello qui descritto hanno, ovviamente, i loro svantaggi: per esempio si potrebbe votare molto un talk tenuto da un perfetto incompetente che risulterebbe in uno speech di pessima qualità, trascurando magari talk meno "accattivanti" ma di sicuro successo ed impatto.
E forse alcune persone non vogliono selezionare di propria volontà i talk, quanto lasciare che siano gli organizzatori a "stupirli" con contenuti all'altezza di stimolare la curiosità e l'intelletto.
Tuttavia è difficile rimanere in un ambito o nell'altro se non si hanno dati alla mano circa il gradimento delle precedenti edizioni (questione che spesso ho sollevato).

Personalmente ritengo che aprire almeno una porzione del PGDay.IT ad un sistema di votazione diretta possa dare quella spinta ad autori e partecipanti per sentirsi maggiormente coinvolti e, soprattutto, per poter decidere il livello dei contenuti da visionare, garantendo quindi una maggiore partecipazione (almeno in teoria).
Se poi il tutto viene accompagnato anche da un feedback sui talk, si può avere una base dati abbastanza oggettiva che possa permettere un evento migliore ad ogni edizione.

Per sessioni interattive penso che un sistema di gradimento anticipato sia fondamentale: organizzare una sessione interattiva (es. ITPUG-Lab) non è semplice e rischia di portare via risorse (sia organizzatori che partecipanti) dalle track della conferenza. Occorre quindi essere certi del gradimento e della partecipazione alla sessione.

Insomma, una sfida interessante e uno spunto per i prossimi organizzatori dell'evento perché si possa sempre migliorare e non "sedimentare" su formule sempre uguali e ripetute.

giovedì, 23 febbraio

22:22

Quali parte sono "colpite" dalle statistiche PostgreSQL? [:: Luca Ferrari ::]

Ecco una interessante immagine che rende l'idea di quali parti del complesso e completo sistema di statistiche PostgreSQL. L'immagine mostra quali viste usare a seconda della parte di backend/stack che si vuole monitorare.
Per l'articolo originale si veda qui:


martedì, 21 febbraio

17:12

PostgreSQL @ Python [:: Luca Ferrari ::]

Il legame tra Python e PostgreSQL appare sempre piu' forte.
Se da un lato ITPUG sarà anche per questa edizione media partner della conferenza italiana PyCon 8 , la community PostgreSQL viene citato nella sezione Community per l'internazionale PyCon 2017.

venerdì, 03 febbraio

17:55

GitLab, PostgreSQL, e la perdita accidentale dei dati [:: Luca Ferrari ::]

Un socio di ITPUG ha indicato un articolo interessante riguardante un incidente informatico capitato a GitLab. A parte il tecnicismo e l'errore, forse grossolano e sicuramente dettato dallo stress e la fretta (chi è senza peccato scagli la prima pietra...), la parte interessante dell'articolo è l'apertura e la documentazione che GitLab ha voluto fornire a seguito dell'accaduto.
Sicuramente questo atteggiamento ha permesso a GitLab di uscire "meglio" dal disastro, poiché quasi tutti gli sviluppatori hanno apprezzato la documentazione fornita, che ha consentito uno studio postumo utile a chi si troverà in simili situazioni.

venerdì, 27 gennaio

21:08

TAP: alcuni concetti [:: Luca Ferrari ::]

Il Test Anything Protocol (TAP per gli amici) è un formato semplice ed efficace per la reportistica di test automatici.
Nato nell'ecosistema Perl nel 1988, il protocollo si è evoluto ed è uscito dai confini Perl per giungere ad altri linguaggi e sistemi, perfino database con PostgreSQL e pgTap.

Il formato TAP è abbastanza semplice e si basa su alcuni concetti semplice:
  • producer è un'applicazione che si occupa di produrre un output TAP compatibile (su stdout)
  • consumer è un'applicazione che si occupa di interpretare l'output di un producer e fornire un report finale.

Ad esempio "prove" è un consumer dell'output prodotto da "Test::More" e similari, che a sua volta fungono da producer.
Nell'esempio relativo a PostgreSQL si ha che "pg_prove" è un consumer, e le funzioni importate da pgTap e i relativi script SQL sono i producer.

Il formato TAP è abbastanza semplice e prevede un solo paio di elementi obbligatori.
Anzitutto occorre inserire il numero di test, ovvero il piano di esecuzione, indicato come 1..N (con N > 0), e solitamente questo compare come primo elemento nell'output. Grazie a questa informazione il consumer sa se ha raggiunto la fine dei test (N) correttamente o se qualcosa ha causato un abort del sistema. Con l'evoluzione TAP supporta anche che N sia zero, indicando così che si vuole saltare la porzione di test. Inoltre è possibile specificare il piano di esecuzione alla fine, che in altre parole è come dire che non c'è un vero piano di esecuzione.

Successivamente, per ogni test effettuato, ci deve essere almeno una riga che inizia con "ok" oppure "not ok". Questo è l'unico elemento obbligatorio, anche se altri sono suggeriti per una migliore comprensione e analisi dei tool consumer.
Subito dopo lo stato del test si dovrebbe indicare il numero progressivo del test stesso, come pure una descrizione del test (affinché si possa capire meglio quale test è stato eseguito). Da ultimo vi è la possibilità di una direttiva (commentata in stile Perl, ossia con "#") che può indicare di saltare il test (SKIP) o che il test non è ancora completo (TODO).

Riassumento l'output di TAP può essere considerato come:


<# direttiva>

Ed ecco quindi un esempio pratico:

1..2
ok 1 - First comparison test
ok 2 - Second comparison


Qualora il piano di esecuzione non sia corretto TAP dovrebbe fornire una indicazione (non una direttiva) di tale fatto:

1..10
ok 1 - First comparison test
ok 2 - Second comparison
# Looks like you planned 10 tests but ran 2.

Solitamente durante la fase di sviluppo non si utilizza un piano di esecuzione, ma all'atto del rilascio del software il piano di esecuzione deve essere "congelato" in modo da aumentare la verifica automatica di errori.


Nell'output di TAP tutte le linee che iniziano con un commento in stile Perl ("#") vengono ignorate e usate, ad esempio, per fornire all'utente dei messaggi diagnostici per aiutarlo a capire perché un test è fallito.

Una direttiva di emergenza, denominata "Bail out!", indica che il sistema di test ha deciso di non proseguire per errori (controllati) troppo gravi. Ad esempio si può annullare una sessione di testing perché la rete non è disponibile, o il compilatore non è alla versione corretta, ecc.

Nel caso in cui non sia fornito un vero piano di esecuzione, e quindi l'output di TAP non inizi con "1..N", il sistema non sa quanti test deve eseguire. In questa eventualità si deve procedere con i test, aumentando in modo incrementale l'eventuale numero riportato in uscita, e alla fine stampando il "presunto" piano di esecuzione:

ok 1 - First comparison test
ok 2 - Second comparison
1..2

Tuttavia in questo caso il sistema non può sapere autonomamente se i test sono finiti o se c'è stato un abort di esecuzione, e per questo si richiede al programmatore di inserire una chiamata di fine esecuzione (ad esempio in Perl done_tsting() ).


Fino a qui ci si è occupati di TAP dal lato del producer. L'output di TAP viene poi analizzato a sua volta da un consumer, ad esempio "prove" o "pg_prove" che forniscono un riassunto su quanti test sono stati eseguiti, quanti sono andati bene e quanti sono falliti. L'idea dei consumer è che, all'aumentare del numero di test, l'utente dovrebbe potersi concentrare solo sul risultato finale e non sui singoli output dei vari test.

Per maggiori informazioni sulle specifiche TAP si veda qui.

16:04

Reboot ITPUG (Le mie dimissioni da ITPUG...parte 3) [:: Luca Ferrari ::]

Il consiglio di ITPUG è nuovamente in forze: dopo le mie dimissioni di circa un mese fa è stato eletto un nuovo socio per sostituirmi.
Questo permetterà ad ITPUG di proseguire le normali attività fino alle prossime elezioni di fine biennio, direi Aprile.
Presto sparirà il mio nome dalla lista dei consiglieri , immagino ci vorrà tempo perché si dia la giusta visione al mio sostituto.

A seguito delle mie dimissioni ho assistito ad un approccio abbastanza roccambolesco nella gestione del da farsi. Premesso che non ho intenzione di polemizzare e che quanto qui descritto rappresenta solo (e ovviamente) il mio punto di vista, ecco cosa è successo.

Anzitutto un po' di delusione perché le mie dimissioni non sono nemmeno state verbalizzate. Non è mania di protagonismo, ma un consiglio che vuoel una gestione trasparente deve quanto meno prendere atto di quanto sta accadendo al suo interno e "scolpirlo" nella pietra. Amarezza anche per la presidenza, che nonostante io avessi chiesto si pronunciasse, si è limitata a convocare l'assemblea straordinaria.

Stupore anche per la decisione, quasi unilaterale e a colpi di rima baciata (ossia in modo molto prolisso), di delegittimazione del consiglio stesso. Essendone io uscito si è deciso, applicando in maniera molto rigida e forse non regolare lo statuto, di delegittimare il consiglio stesso. A nulla è servito portare alla memoria dei consiglieri (alcuni storici quasi quanto me) e dei soci che già in passato, in analoga situazione e con dimissioni presentate, il consiglio aveva comunque proseguito la sua attività. E a nulla è servito ricordare che anche i soci pendenti potevano essere ammessi all'associazione (anche perché lo statuto stesso prevede 30 giorni per una decisione).

I soci stessi sono stati posti in discussione, utilizzando una logica boolean abbastanza contorta per la quale chi non aveva pagato/rinnovato la quota 2017 risultava "non in regola" e quindi non ammesso alle votazioni del mio sostituto. Ora, in assenza di un regolamento specifico e considerato che le quote vengono rinnovate in occasione dell'assemblea ordinaria (solitamente Aprile), questa mi è sembrata una contromisura molto forte. Inoltre, non essendoci un termine stabilito per il rinnovo, definire la morosità dei soci risulta abbastanza discutibile.
E anche qui i consiglieri storici avrebbero potuto ricordarsi di cosa accaduto nel 2014, situazione differente ma valutazione di "morosità" analoga.
Ancora peggio: c'è la garanzia che i consiglieri fossero tutti in regola con la quota?
E se non lo erano, anche se per un breve periodo nel loro mandato, il consiglio non deve essere analogamente delegittimato?

Ma andiamo avanti. E' stata convocata una assemblea straordinaria dei soci, sbagliandone la convocazione e facendo quindi slittare di un giorno l'assemblea stessa. Che poi è stata verbalizzata come ordinaria, e non come straordinaria.
Piccolezze, sviste, e concordo! Ma una associazione che vuole applicare rigidamente lo statuto non può fare simili sviste, almeno secondo me.
E se anche succedono queste sviste, perché in un caso la convocazione è stata annullata (ritardando quindi la "rilegittimazione" del consiglio) e nell'altro caso no?

Insomma, come si evince, ritengo che sia stato applicato uno statuto mirato piu' a legare le mani all'associazioni che non a sostenere la stessa.
Fermo restando che l'approccio difensivo difficilmente risulta inadeguato, forse questo accanimento ha causato piu' danni che utile.

Detto questo penso, in tutta onestà, che a parte i miei impedimenti personali forse è un bene che io sia uscito da questo consiglio: le incongruenze fra il mio modo di vivere l'associazione e quello degli altri membri è ormai abbastanza distante, e questo avrebbe comunque impedito un sano lavoro di entrambi.

In bocca al lupo al nuovo consiglio, e buon lavoro!
Sperando che si riprenda a pubblicare ai soci i verbali delle riunioni, anche questi trattenuti a colpi di statuto...

Un'ultima nota: fino alle mie dimissioni io sono stato l'unico consigliere ad essere stato in carica dall'inizio dell'attività ITPUG con assoluta continuità. Ahimé ritengo che la mia memoria storica non sia stata utilizzata in modo costruttivo come avrebbe potuto.

P.S.
dai messaggi che passano in lista soci penso di sapere chi sarà il prossimo presidente: 47605db981f8

mercoledì, 18 gennaio

20:14

Quanto ITPUG? (Le mie dimissioni da ITPUG parte 2) [:: Luca Ferrari ::]

Avendo marcato la fine della mia attività da consigliere con le dimissioni di circa un mese fà, ho deciso, quasi per curiosità, di cercare di quantificare il lavoro svolto da ITPUG e dal suo consiglio negli ultimi due mandati.
Si tratta di dati ovviamente indicativi, visto che strumenti diversi offrono opzioni di statistica differenti, ma possono essere utilizzati per un grezzo lavoro di analisi quantitativa.
E' bene sottolinearlo: si parla di attività quantitativa, non qualitativa!
Tuttavia l'attività quantitativa spesso indica e sottointende la presenza in associazione e la vitalità della stessa, da qui il mio interesse per questi semplici dati.

Ovviamente non sto svelando alcun segreto, questi dati sono comunque visibili e calcolabili da ogni consigliere e socio, con un po' di impegno e pazienza. Potrei anche aver commesso qualche errore di computazione, nel qual caso ogni correzione è ben accetta.

Considerando quindi la data del 30 aprile come termine di un biennio (e il relativo inizio del successivo), e sottolineando come il biennio 2015-2017 non sia ancora giunto al termine (e quindi i dati di tali biennio si riferiscono alla data attuale), si ha che:
  • biennio 2013-2015
  1.  301 commits
  2. 281 tickets
  3. 19 verbali riunioni di consiglio
  4. 108 thread in lista itpug-consiglio@
  5. 170 thread in lista itpug-soci@
  • biennio 2015-2017
  1. 103 commits
  2. 190 tickets
  3. 7 verbali riunioni di consiglio
  4. 160 thread in lista itpug-consiglio@ 
  5. 130 thread in lista itpug-soci@

L'attività del consiglio può essere quantificata con il numero di commits nel repository documentale, ovvero quanti documenti il consiglio ha ritenuto di inserire fra quelli ufficiali (fra questi, i verbali delle riunioni di consiglio), nonché dal numero ti tickets (ovvero di problematiche e task da affrontare). Come si può notare il valore di entrambi è drasticamente calato nell'ultimo biennio, segno che non si utilizza piu' né il repository né il sistema di ticketing come strumento base per la gestione delle attività del consiglio.
Questo è in parte confermato anche dall'aumento del numero di thread nella mailing list consiglio, che rispecchia il maggior uso e preferenza di questo canale di discussione rispetto agli altri strumenti.
A mio avviso questa è una regressione, poiché l'email non rappresenta lo strumento ideale per gestire scadenze, priorità, condivione di documenti.
Il dato però piu' allarmante, a mio avviso, è quello delle riunioni di consiglio, o meglio, dei verbali delle riunioni di consiglio. Come si può vedere le riunioni di consiglio sono scese del 60% circa, segno che il consiglio non ritiene sufficientemente utile riunirsi con regolarità (ulteriore conferma della preferenza del canale e-mail), o ha delle difficoltà a riunirsi.
Appare anche diminuita l'attività e la presenza del consglio nella mailing list dei soci, visto che il numero di thread si è abbassato. Ora, questo dato in particolare non coinvolge direttamente il consiglio, visto che i thread possono anche essere creati dai singoli soci (e anzi, questo è quello che dovrebbe accadere); tuttavia l'abbassamento del numero di discussioni evidenzia, secondo me, un raffreddamento del "networking" fra i soci al quale il consiglio dovrebbe cercare di porre rimedio.

Lascio ad altri il computo dei post e della frequenza di aggiornamento del planet italiano perché sarei sicuramente male interpretato.

ITPUG ha una struttura di supporto informatico sicuramente complessa e funzionale (si veda qui), di gran lunga superiore a quella di molte altre associazioni PostgreSQL analoghe. Ritengo sia di vitale importanza per l'associazione che ogni consiglio riesca ad usare al meglio questa infrastruttura, nonché la storia che essa contiene (archivi, logs, ecc.) poiché rappresenta un bagaglio culturale di enorme valore.

venerdì, 13 gennaio

17:59

Josh Berkus lascia il core team di PostgreSQL [:: Luca Ferrari ::]

E' di ieri la notizia che Josh Berkus, uno dei membri del core-team di PostgreSQL, si dimette dal core team stesso, e in effetti come diretta e rapida conseguenza non appare piu' il suo nome nell'elenco dei contributor (si veda il suo annuncio ufficiale qui.

Ho avuto poche occasioni di vedere Josh dal vivo, e quello che mi ha sempre colpito è la sua capacità come speaker, oltre alle sue competenze tecniche dettate da una grande esperienza. Ma un'altra cosa mi ha sempre colpito: Josh si è sempre dimostrato (nelle sue apparizioni nonché nelle sue comunicazioni nelle varie mailing list) una persona corretta e aperta, in una sola parola mi ha sempre dato l'impressione di essere una persona "pura" per quanto riguarda il progetto stesso.
Questo perché, a differenza di altri membri del progetto, si sono viste anche reazioni molto piu' business-oriented e meno community-centric.

Ritengo che Josh abbia svolto un ruolo molto importante per l'advocacy e la qualità del progetto PostgreSQL e, anche se il team è composto da persone piu' che valide, penso sarà difficile rimpiazzare pienamente un simile personaggio.

venerdì, 06 gennaio

18:55

Le mie dimissioni da ITPUG [:: Luca Ferrari ::]

Cari soci,
anzitutto buon anno (anche se in ritardo)!
E' con dispiacere e un po' di imbarazzo che vi informo che qualche giorno addietro, precisamente prima di Natale, ho presentato le mie dimissioni dal ruolo di consigliere.
La mia partecipazione in ITPUG si è ridotta per cause esterne, e ultimamente mi trovo anche in difficoltà nel rappresentare l'associazione.
In considerazione di tutto ciò, sperando nel meglio per l'associazione, e senza voler occupare un ruolo in modo "sterile", mi faccio quindi da parte.

Preciso, qualora necessario, che dalla data della presentazione delle mie dimissioni mi sto astenendo da esprimere ogni opinione in consiglio, se non espressamente richiesto.

Ho seguito e servito ITPUG dalla sua costituzione, la ritengo una esperienza interessante ed utile, grazie anche a voi.

Ad ogni modo non vi sbarazzerete facilmente di me, e ci ritroveremo a conferenze e sui vari canali informatici come al solito!

Grazie,
Luca



Questa è la lettera che ho inviato nella mailing list soci di ITPUG per confermare le mie dimissioni dal ruolo di consigliere.
Niente di drammatico, né tanto meno melodrammatico, ma spero con questo mio post di poter chiarire meglio la situazione e la mia decisione, che sono certo potrà essere interpretata negativamente, molto piu' di quanto non lo sia.

La parola chiave di tutto questo è coerenza.
Coerenza con me stesso, con gli impegni presi, con l'associazione che ho contribuito a creare e che ho risollevato.
Non posso piu' onorare gli impegni presi, perché vicissitudine esterne ad ITPUG mi tengono lontano dall'associazione, e di questo ne sono mortificato.
Quindi, per coerenza con l'impegno preso, trovo corretto farmi da parte.
Ma c'è anche la coerenza con me stesso: io ho una visione della vita di associazione che, sicuramente per una mia interpretazione sbagliata, tende a stridere con quanto osservo ultimamente in ITPUG. In particolare se ripenso all'enorme impegno che mi ero assunto come presidente anni fà, quando sono riuscito a risollevare (non da solo!) sia l'associazione, prossima alla chiusura, che il PGDay.IT; entrambi versavano ormai in uno stato comatoso e sicuramente non open.

Come ho scritto brevemente sopra è stata una esperienza interessante, ma anche impegnativa. Sono passato attraverso molte soddisfazioni e anche molte delusioni, perfino interrogativi. Mi sono state rivolte belle parole e brutte parole, perfino azzardi su conflitti di interesse. Sorrido se ci ripenso, anche perché per me PostgreSQL non è mai stato piu' che un hobby, una passione. E anche perché, se ben ricordo, all'ultimo PGDay.IT al quale ho partecipato sono stato l'unico organizzatore a segnarsi come membro ITPUG invece che di una azienda, ente, università.

Ho sempre tentato di svolgere una attività sana e alla luce del sole, cercando di dare pari opportunità a tutti quanti. Ho sempre tentato di portare avanti il nome dell'associazione, facendola comparire anche nel planet.postgresql.org, sulle riviste per le quali scrivevo articoli, e nelle piccole interviste fatte.

Ho conosciuto molta gente interessante, molti stereotipi altrettanto interessanti e molte realtà aziendali ed enti che fanno duro lavoro per mantenere quello spirito open che mi ha sempre affascinato.

Ora, inutile farla tanto melodrammatica: non sarò stato infallibile, non sarò stato impeccabile, ma ho speso veramente tante energie per questa associazione, e il solo fatto che sia qui a scrivere a riguardo testimonia quanto sia stata per me una decisione difficile.

Perché anticipare le dimissioni visto che il consiglio sta per giungere alla sua "naturale" scadenza? Già, è una domanda lecita, sulla quale i maliziosi potranno lucrare teorie complottiste, ma la questione è realmente semplice come eseguire una rollback.
Il fatto è che non mi sento piu' di fare parte del consiglio, e avere senzazioni senza-azioni non è da me. Come dicevo, coerenza...

Cosa succederà adesso?
Beh, niente panico! ITPUG ha un consiglio formato da gente esperta che saprà portare avanti l'associazione. Dopotutto io non sono certo indispensabile!
E comunque mi rendo disponibile ad affiancare il consiglio qualora lo si riterrà opportuno.

mercoledì, 21 dicembre

11:10

PGDay.IT 2016 [2ndQuadrant]

img_6093-jpgAnche quest’anno si è svolto il PGDay, evento annuale organizzato dall’ITPUG, l’associazione italiana di PostgreSQL. Nonostante i membri dell’associazione siano sparsi per tutto il territorio nazionale, la decima edizione si è svolta nella città che ha dato i natali all’associazione ITPUG, Prato, la mia città.

Durante la manifestazione ho avuto il piacere di dare il mio contributo alla comunità, presentando un talk riguardo l’installazione di PostgreSQL su Network File System. Nel talk ho raccontato una mia esperienza professionale condivisa con il mio collega Giuseppe Broccolo, nel quale testavamo l’affidabilità di Postgres su NFS.

Condividere la mia esperienza su PostgreSQL con gli altri partecipanti all’evento è stato piacevole e costruttivo.

Ho potuto apprezzare i talk di Denis Gasparin sui diversi tool per l’upgrade tra major release di PostgreSQL oltre al keynote tenuto da Giorgio Roncolato, Direttore Sistemi Informativi ULSS 5 di Arzignano, sulla migrazione all’Open Source, dimostrando quanto i tempi siano maturi anche per le istituzioni, sempre più sensibili all’argomento Software Libero.

Come non menzionare i divertenti talk animati di Mladen Marinovic, coi quali è riuscito a trasmettere l’importanza del testing e della code review intrattenendo la platea e regalando momenti di ilarità.

Manifestazioni di questo tipo permettono la condivisione della conoscenza attraverso i dibattiti e le discussioni che nascono sia al termine di ogni talk che durante i momenti di networking.

L’evento mi ha dato l’oppurtunità di stringere nuove amicizie e di rafforzarne altre già confermate. La giornata si è conclusa con un aperitivo che ha portato ad uno scambio di opinioni, prolungando il tempo di permanenza di alcuni partecipanti.

martedì, 13 dicembre

14:47

PgDay.IT 2016: ci siamo (senza di me) [:: Luca Ferrari ::]

Oggi è la giornata del decimo PgDay.IT.
Sono passati già dieci anni dal primo evento organizzato da un gruppo di "ragazzotti" aggregati in un modo abbastanza disorganizzato ma efficace.
Io ne entrai a far parte per caso: era il 2007 e stavo iniziando un progetto importante basato su PostgreSQL, e così, cercando gruppi di discussione in italiano capitai sopra ad una rudimentale pagina wiki che parlava di un evento interamente dedicato a questo database.
Mandai quindi una mail di disponibilità e il gioco fù fatto: ero uno degli organizzatori dell'evento, il quale si dimostrò da subito molto importante per la comunità internazionale.
Da lì si formò ITPUG, l'associazione che nelle nove edizioni passate ha organizzato le altrettante versione dell'evento.

Quest anno, purtroppo, non potrò partecipare all'evento, per ragioni personali. Anche la mia partecipazione nell'organizzazione dell'evento è stata meno incisiva rispetto agli anni passati.

In generale però posso affermare di non essere stato l'unico ad aver contribuito in maniera ridotta a questo PgDay.IT, e l'impressione generale e che mi viene riportata è quella di un evento sottotono. Spero che l'organizzazione possa dimostrare il contrario; il programma e la partecipazione parlano da soli.

Ma il dispiacere piu' grande non è certo quello di non avere un evento colossale, quanto quello di non poter passare una giornata intera a parlare ed ascoltare le avventure di PostgreSQL, di non poter rivedere amici di conferenza (e non solo) e bere una buona birra in loro compagnia.

Ma ci saranno altri eventi, altre conferenze, altri PgDay.IT e altre birre per recuperare il tempo perso!

Buon evento a tutti.

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!