Tra le novità introdotte da PostgreSQL 10 sicuramente una delle più importanti è l’implementazione della replica logica nel core di Postgres.

Molti di voi avranno già provato o almeno sentito parlare di pglogical, estensione di PostgreSQL che fornisce il supporto per la replica logica, che, grazie al logical decoding dei WAL (presente dalla 9.4), permette di replicare una selezione di tabelle da un database ad un altro.

In questo articolo vedremo come adesso questo è possibile con PostgreSQL 10 e quali sono le differenze con pglogical. Inoltre, viene assunto che il lettore abbia una preparazione di base sulle nozioni di amministrazione di PostgreSQL e di manipolazione dei file di configurazione e di sicurezza.

Cos’è?

La replica logica si basa sull’architettura Pubblicazione/Sottoscrizione, si differenziano quindi due ruoli: un publisher e un subscriber. A differenza di quella fisica nella quale vengono replicate tutte le modifiche a livello binario, la replica logica permette di filtrare i cambiamenti da replicare scegliendo le tabelle e una combinazione di operazioni su di esse tra UPDATE, INSERT e/o DELETE. Per esempio è possibile replicare solo le UPDATE di una singola tabella da un server ad un altro a scopo di analisi e/o di aggregazione dei dati.

Come funziona

Sul publisher viene definita una “pubblicazione”, ovvero una selezione delle tabelle (o tutte) di un database a cui vengono associate le operazioni da replicare ai subscriber. Grazie alla decodifica logica dei WAL le operazioni sono ricostruite traducendo il codice binario e vengono selezionate solo quelle definite nella “pubblicazione” per essere trasmesse ai subscriber.

Configurazione

L’installazione di default predispone già impostate alcune delle opzioni necessarie a configurare la replica logica.

Per quanto riguarda il publisher:

• max_replication_slots = 10
  Almeno uno per ogni subscriber più alcuni per l’inizializzazione delle tabelle.
• max_wal_senders = 10
  Almeno uno per ogni replication_slot più quelli necessari per le repliche fisiche (es.: Barman).

Per quanto riguarda il subscriber:

• max_logical_replication_workers = 4
  Uno per sottoscrizione, più alcuni da considerare per la sincronizzazione delle tabelle.
• max_worker_processes = 10
  Almeno uno per ogni replication workers più uno.

[NOTA] Queste però non bastano per attivare la replica logica. Quello che manca, infatti, sono le informazioni all’interno del codice dei WAL necessarie per ricostruire le operazioni da filtrare e inviare ai subscriber. Per ottenere queste informazioni è necessario impostare sul publisher il parametro wal_level a logical e avviare (o riavviare) il servizio.

L’unico cambiamento che dobbiamo apportare è il seguente parametro sul publisher pippo-pg10:

• wal_level = logical

I valori preimpostati sono più che sufficienti per questo test. Tuttavia, va tenuto conto che sono parametri che vengono valorizzati all’avvio del servizio e quindi ogni ulteriore cambiamento viene applicato solo dopo un nuovo riavvio. In questa ottica è consigliabile impostare valori adeguati al numero di pubblicazioni e sottoscrizioni previsti, prima di dover riavviare il servizio in produzione.

Preparazione

Consideriamo un caso reale di utilizzo della replica logica, prendendo di esempio un cluster con due server PostgreSQL 10:

• pippo-pg10, ip: 192.168.42.110, publisher
• paperino-pg10, ip: 192.168.42.210, subscriber

Sul server pippo-pg10 sono presenti le tabelle che devono essere replicate su un database del server paperino-pg10, precedentemente create con pgbench, un tool molto utile per misurare le prestazioni di PostgreSQL.

[root@pippo-pg10 ~]# sudo -iu postgres
-bash-4.2$ psql

psql (10beta4)
Type "help" for help.
postgres=# \c pgbench
You are now connected to database "pgbench" as user "postgres".
pgbench=# \d
               List of relations
 Schema |       Name       | Type  |   Owner
--------+------------------+-------+------------
 public | pgbench_accounts | table | user_bench
 public | pgbench_branches | table | user_bench
 public | pgbench_history  | table | user_bench
 public | pgbench_tellers  | table | user_bench
(4 rows)

Creazione Tabelle

A causa delle restrizioni sulla replicazione non è possibile replicare la definizione di una tabella tanto meno di un database. Per questo occorre replicare manualmente la definizione sul server di sottoscrizione, per esempio partendo da un dump dello schema del database pgbench dal publisher:

-bash-4.2$ pg_dump -s -f pgbench.sql

Quindi creare l’utente e il database di destinazione nell’istanza PostgreSQL di paperino-pg10 (operazioni assenti nello script appena estratto):

[root@paperino-pg10 ~]# sudo -iu postgres
-bash-4.2$ createuser user_bench
-bash-4.2$ createdb pgbench -O user_bench

[NOTA] Non è necessario che l’utente e il database abbiano lo stesso nome, ma in questo caso si utilizza lo stesso nome per semplicità.

Adesso è possibile applicare lo script SQL sul server paperino-pg10:

-bash-4.2$ psql -d pgbench  < pgbench.sql
SET
SET
SET
SET
SET
SET
SET
SET
SET
CREATE EXTENSION
COMMENT
SET
SET
SET
CREATE TABLE
ALTER TABLE
CREATE TABLE
ALTER TABLE
CREATE TABLE
ALTER TABLE
CREATE TABLE
ALTER TABLE
ALTER TABLE
ALTER TABLE
ALTER TABLE

Creazione Ruolo Replicazione

Nell’istanza pippo-pg10 è necessario creare il ruolo dedicato alla replicazione e definire opportunamente la regola nel pg_hba.conf che permetta la connessione dal subscriber paperino-pg10.

pgbench=# create role replica superuser replication;
CREATE ROLE

Creazione Pubblicazione

Una pubblicazione è definita come un set di cambiamenti su una o più tabelle appartenenti ad un solo database. Si possono creare più pubblicazioni in un solo database scegliendo di replicare una tra le operazioni di INSERT, UPDATE e DELETE o una loro combinazione. Ogni tabella può appartenere a più pubblicazioni e una singola pubblicazione può avere più sottoscrizioni.

In questo esempio assumiamo di voler replicare tutte le operazioni di modifica su tutte le tabelle di un database. Per creare questo tipo di pubblicazione è necessario essere superutenti (maggiori dettagli):

pgbench=# CREATE PUBLICATION pgbench_alltables FOR ALL TABLES;
CREATE PUBLICATION

Creazione Sottoscrizione

Una sottoscrizione viene definita su un nodo PostgreSQL, chiamato subscriber, con una connection string verso il server publisher e una lista di una o più pubblicazioni alle quali sottoscriversi. Il nome della sottoscrizione viene trasmesso al publisher come riconoscimento della connessione se non è definito il campo application_name nella stringa di connessione.

Per creare una sottoscrizione è necessario essere superutenti (maggiori dettagli).

Su paperino-pg10:

pgbench=# CREATE SUBSCRIPTION pgbench_rep CONNECTION 'dbname=pgbench host=192.168.42.110 user=replica' PUBLICATION pgbench_alltables;
NOTICE:  created replication slot "pgbench_rep" on publisher
CREATE SUBSCRIPTION

[NOTA] Un replication slot viene creato per ogni sottoscrizione, più uno temporaneo per la sincronizzazione iniziale dei dati.

Adesso è possibile controllare che l’inizializzazione dei dati nel subscriber rispecchi la situazione nel publisher:

sul publisher pippo-pg10

postgres=# \c pgbench
You are now connected to database "pgbench" as user "postgres".
pgbench=# select * from pg_publication;
      pubname      | pubowner | puballtables | pubinsert | pubupdate | pubdelete
-------------------+----------+--------------+-----------+-----------+-----------
 pgbench_alltables |       10 | t            | t         | t         | t
(1 row)

pgbench=# select * from pgbench_branches limit 5;
 bid | bbalance | filler
-----+----------+--------
   1 |        0 |
   2 |        0 |
   3 |        0 |
   4 |        0 |
   5 |        0 |
(5 rows)

pgbench=# select * from pgbench_tellers limit 5;
 tid | bid | tbalance | filler
-----+-----+----------+--------
   1 |   1 |        0 |
   2 |   1 |        0 |
   3 |   1 |        0 |
   4 |   1 |        0 |
   5 |   1 |        0 |
(5 rows)

e sul subscriber paperino-pg10

postgres=# \c pgbench
You are now connected to database "pgbench" as user "postgres".
pgbench=# select * from pg_subscription;
 subdbid |   subname   | subowner | subenabled |                   subconninfo                   | subslotname | subsynccommit |   subpublications
---------+-------------+----------+------------+-------------------------------------------------+-------------+---------------+---------------------
   16532 | pgbench_rep |       10 | t          | dbname=pgbench host=192.168.42.110 user=replica | pgbench_rep | off           | {pgbench_alltables}
(1 row)

pgbench=# select * from pgbench_branches limit 5;
 bid | bbalance | filler
-----+----------+--------
   1 |        0 |
   2 |        0 |
   3 |        0 |
   4 |        0 |
   5 |        0 |
(5 rows)

pgbench=# select * from pgbench_tellers limit 5;
 tid | bid | tbalance | filler
-----+-----+----------+--------
   1 |   1 |        0 |
   2 |   1 |        0 |
   3 |   1 |        0 |
   4 |   1 |        0 |
   5 |   1 |        0 |
(5 rows)

Le tabelle sul server paperino-pg10 sono state inizializzate!

Test Replica

Il test consiste nel verificare che le modifiche apportate alle tabelle sul server pippo-pg10 siano effettivamente replicate su paperino-pg10.

Su pippo-pg10:

pgbench=# BEGIN;
BEGIN
pgbench=# SELECT * FROM pgbench_accounts WHERE aid = 1;
 aid | bid | abalance |                                        filler
-----+-----+----------+--------------------------------------------------------------------------------------
   1 |   1 |        0 |
(1 row)

pgbench=# UPDATE pgbench_accounts SET filler = 'Jonny was here' WHERE aid = 1;
UPDATE 1
pgbench=# select * from pgbench_accounts where aid = 1;
 aid | bid | abalance |                                        filler
-----+-----+----------+--------------------------------------------------------------------------------------
   1 |   1 |        0 | Jonny was here
(1 row)
pgbench=# COMMIT;
COMMIT
pgbench=#

Una volta eseguito il COMMIT nel WAL viene scritta l’operazione UPDATE appena eseguita e replicata al subscriber:

pgbench=# select * from pgbench_accounts where aid = 1;
 aid | bid | abalance |                                        filler
-----+-----+----------+--------------------------------------------------------------------------------------
   1 |   1 |        0 | Jonny was here
(1 row)

Attenzione! Le operazioni di UPDATE e DELETE sono replicate al subscriber solo sulle tabelle che possiedono una REPLICA IDENTITY, che di default è la chiave primaria. La tabella history di pgbench non sarebbe stata replicata in caso avessimo creato una pubblicazione limitata alle UPDATE e/o DELETE, perché non possiede una chiave primaria.

Considerazioni Conclusive

Replica Logica vs. Replica Fisica

La replica logica a differenza della replica fisica di un’istanza in hot-standby mode, non è da considerarsi un’architettura Master/Standby in quanto il subscriber è egli stesso un master, permettendo quindi le scritture su tutte le tabelle. Può essere comunque utilizzata in maniera simile usando utenti con permessi di sola lettura sul subscriber fino al prossimo switchover.

Per l’architettura multi-master, nella quale le modifiche vengono effettuate concorrentemente su più nodi, si rimanda alla lettura del sistema BDR.

Questa tecnologia permette di migrare da una major version di PostgreSQL ad un’altra, al contrario della replica fisica a causa dell’incompatibilità binaria tra differenti versioni.

Differenze con pglogical

L’implementazione nel core di PostgreSQL 10 della replica logica è un’eredità del progetto pglogical, che, essendo più maturo, possiede molte funzionalità in più. Tra le caratteristiche più importanti di pglogical vi è la possibilità di replicare le modifiche allo schema di un database e le DDL, quindi le definizioni delle tabelle. Inoltre è possibile configurare la risoluzione dei conflitti, mentre con PostgreSQL 10, in caso di conflitto la replica logica si interrompe ed è necessario l’intervento umano per la sua risoluzione. Un’altra funzionalità che rende pglogical molto potente è la possibilità di replicare specifiche righe e/o colonne di una tabella.

Commenti

L’inizializzazione dei dati nelle tabelle del subscriber è una funzionalità molto utile, ma è possibile scegliere di non effettuarla durante la creazione della sottoscrizione.

Anche la replica logica può essere sottoposta alle stesse configurazioni di sincronizzazione delle transazioni tra standby e master, in modo da avere una perdita dati zero. Sono sufficienti gli stessi parametri della replica fisica per ottenere la sincronizzazione tra master e standby.

Nell’esempio di questo articolo, per attivare la replica logica sincrona è sufficiente configurare i seguenti parametri:

synchronous_commit = remote_apply
synchronous_standby_names = pgbench_rep

e riavviare PostgreSQL.

Il valore del parametro synchronous_standby_name corrisponde al nome della sottoscrizione. Maggiori dettagli sulla configurazione del parametro synchronous_standby_names.

Adesso mi rimane una domanda: qual è la differenza di velocità fra la replica fisica e quella logica? Potrebbe essere l’interessante argomento del mio prossimo articolo.

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.

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!

La seconda edizione del 5432… MeetUs! si terrà a Milano, il 28 e 29 giugno 2016.

Se ancora non hai risposto alla “Call for Paper”, sei ancora in tempo!

Tante le proposte pervenute, alcuni Ospiti e Testimonial di PostgreSQL hanno già confermato la loro presenza. I primi sponsor stanno già dando il loro supporto alla Conferenza.

E tra gli speaker che saranno selezionati potresti esserci proprio tu!

Ti rinnoviamo l’invito: se stai realizzando qualcosa di interessante con PostgreSQL, ti invitiamo ad inviarci una proposta di talk!

La proposta deve contenere un abstract che racconti gli aspetti fondamentali ed i punti salienti del talk che vorresti presentare, una breve biografia correlata di fotografia e i dati dei social ed email che vuoi rendere pubblici.

Topics

Non aspettare troppo! Inviaci la tua proposta di talk!

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.

L’occasione di condividere le proprie esperienze con PostgreSQL e non solo. Una full immersion di due giorni, con l’opportunità di incontrare alcuni dei maggiori esperti, di ascoltare le testimonianze dirette di aziende che lo hanno adottato e di interagire con chi ha fatto di PostgreSQL la propria mission. Grande novità di questa edizione è l’apertura a nuovi argomenti: non si parlerà solo di PostgreSQL ma anche di tecnologie con cui PostgreSQL è coinvolto.

Se stai realizzando qualcosa di interessante con PostgreSQL, ti invitiamo ad inviarci una proposta di talk!

La proposta deve contenere un abstract che racconti gli aspetti fondamentali ed i punti salienti del talk che vorresti presentare, una breve biografia correlata di fotografia e i dati dei social ed email che vuoi rendere pubblici.

Topics

Il calendario della call for paper è il seguente:

• 16 gen 2016 – apertura della call for paper
• 28 feb 2016 – chiusura della call for paper
• 20 mar 2016 – la commissione tecnica informerà l’organizzazione sui talk accettati
• 31 mar 2016 – gli organizzatori invieranno i responsi a tutti coloro che hanno inviato la loro proposta di talk
• 31 mar 2016 – verrà pubblicato il calendario della conferenza

Non esitare, inviaci la tua proposta!

Due giornate dedicate a

PostgreSQL e non solo: grande novità di questa edizione è rappresentata dalla presenza di talk sulle tecnologie con cui PostgreSQL si integra perfettamente, a dimostrazione che pur trattandosi di un DBMS scritto con un linguaggio classico è in grado di affrontare problemi innovativi ottenendo risultati d’eccellenza.

La conferenza sarà così strutturata:

• Talk e relatori I partecipanti avranno a disposizione tre differenti track: una in lingua italiana, una in lingua inglese, l’ultima, la più innovativa è rappresentata da sessioni di workshop di 2 ore ciascuno. A differenza delle conferenze tradizionali, tutti i partecipanti ed i relatori, avranno l’opportunità di mescolarsi, condividere idee e imparare gli uni dagli altri. L’atmosfera rilassata incoraggerà una discussione aperta e franca.

• Eventi sociali, momenti di networking In piena armonia con la filosofia open source verranno riservati spazi per l’interazione e la condivisione tra partecipanti e speaker. L’occasione di stringere importanti rapporti, condividere ed esplorare nuove idee durante momenti di relax come coffee break e pranzi, l’opportunità data ai “One-to-One” e l’immancabile cena sociale del martedì sera!

• Training I giorni successivi alla conferenza (30 giugno e 1 luglio) saranno dedicati ai training. Relatori-tutor seduti “gomito a gomito” con i partecipanti, condivideranno conoscenza e competenza. Un’opportunità da non perdere!

Seguici per tenerti aggiornato e … non mancare!

Il programma si suddivide in talk e training, in modo da prevedere interventi sia teorici che pratici. GoLab si terrà a Prato il 4 dicembre, presso la sede della Camera di Commercio, in via del Romito 71.

Sarà il nostro Leonardo Cecchi a presentare, alle ore 17.15, un talk dal titolo “Il roditore e l’elefante” in cui spiegherà l’importanza dei database relazionali per lo sviluppo delle applicazioni. Nello specifico, parlerà del pacchetto “database/sql”, delle sue particolarità rispetto agli approcci tradizionali e di come utilizzarlo al meglio nelle nostre applicazioni. Parlerà inoltre di “sqlx”, un insieme di estensioni utili sulla libreria “database/sql” che integra le strutture di Go con il database.

Per partecipare alla conferenza occorre registrarsi, con un fee richiesto di soli 15 euro.

Per maggiori informazioni sull’evento: http://golab.io

I posti sono limitati… affrettatevi! Vi aspettiamo numerosi!

Un grandioso successo, con la presenza di oltre 400 partecipanti, a dimostrazione del crescente interesse per PostgreSQL.

Quattro giorni dedicati interamente a PostgreSQL, il più avanzato database opensource del mondo; la prima giornata è stata rivolta alla formazione e le successive ai talk.

Il programma della conferenza è stato denso di contenuti e molto interessante.

Martedì 27 è stato dedicato ai training; variegata è stata l’offerta formativa proposta da alcune delle più attive aziende che fanno parte dell’ecosistema di PostgreSQL. Per 2ndQuadrant Simon Riggs (Major Developer e Committer, PostgreSQL CTO di 2ndQuadrant) e Petr Jelinek (Developer e Consultant di 2ndQuadrant) hanno tenuto il corso su PostgreSQL Replication & Upgrades.

Il calendario dei talk era stato suddiviso per aree di interesse a supporto dei numerosi partecipanti che seguiranno la conferenza: general, keynotes, hacker, developer e DBA. 2ndQuadrant ha dato il suo contributo alla conferenza presentando numerosi talk:

28 ottobre

• Managing PostgreSQL with Ansible – Gulcin Yildirim

• PostgreSQL on the Raspberry Pi 2 – Rubens Souza

• Serializable Transactions, Eventual Consistency and Really Scary Stuff – Simon Riggs

• HA strategy, properly done – Martín Marqués

• Performance improvements in 9.5 and beyond – Tomas Vondra

29 ottobre

• VACUUM, Freezing & Avoiding Wraparound – Simon Riggs

• The Importance of Query Profiling – Gianni Ciolli

• Integrating PostgreSQL with Logstash for real-time monitoring – Gabriele Bartolini e Marco Nenciarini

• PostgreSQL Performance on EXT4, XFS, F2FS, BTRFS and ZFS – Tomas Vondra

A chiusura della giornata, il nostro Harald Armin Massa, ovvero “the lightning talk man“, da perfetto direttore d’orchestra, ha coordinato i lightning talks. L’occasione per i partecipanti di far conoscere (e farsi conoscere), discutere un proprio progetto, un’idea o un’esperienza relativa a PostgreSQL, in soli 5 minuti!

30 ottobre

• Automate High Availability using repmgr 3 – Gianni Ciolli

Hanno concluso la conferenza i keynote tra cui quello di Simon Riggs che ha presentato PostgreSQL Core Roadmap. Simon ha illustrato i progetti attualmente in corso su PostgreSQL, chi ci sta lavorando, su quale funzionalità è impegnato e perché. Una rassegna dei più recenti progetti attualmente in fase di sviluppo oltre ad una panoramica sulle funzionalità che saranno presenti nelle prossime release di PostgreSQL. Funzionalità che aggiungeranno valore in ambito di replica, a livello di prestazioni di query oltre che in scalabilità al più avanzato database opensource del mondo.

L’evento è organizzato dall’associazione no-profit Italian PostgreSQL Users Group (ITPUG), che ha fatto della promozione dell’open source, ed in particolare di PostgreSQL per la gestione di database, l’obiettivo principale.

Acquista ora il biglietto per la conferenza!

Oltre ad essere partner “diamond” del PGDay, 2ndQuadrant sarà presente alla manifestazione con i seguenti talk:

• BDR for DBAs – Martín Marquéz (10:45, Auditorium, in lingua inglese)

• PostgreSQL Disaster Recovery (con BarMan) – Giulio Calacoci (11:30, Sala Conferenze)

• Gli indici BRIN nei database geospaziali – Giuseppe Broccolo (12:15, Sala Conferenze)

• Integrare PostgreSQL con Logstash per il monitoraggio real-time – Gabriele Bartolini, Marco Nenciarini (14:00, Auditorium)

• L’importanza della profilazione delle query – Gianni Ciolli (14:00, Sala Conferenze)

Rappresentante delle aziende che hanno adottato PostgreSQL per la salvaguardia dei loro dati è Pietro Partescano di Subito.it, che presenterà il talk Subito 5432 Hello Word (15:45, Auditorium).

A chiusura della manifestazione, alle 16:30, sono previsti i lightning talk, l’occasione per tutti i partecipanti di diventare protagonisti per 5 minuti, salendo sul palco e condividendo le proprie esperienze e i propri progetti con PostgreSQL.

Un ulteriore contributo a PostgreSQL, è l’estensione redislog, argomento trattato da Gabriele e Marco con il talk “Integrare PostgreSQL con Logstash per il monitoraggio real-time”.

redislog è un’estensione che permette a PostgreSQL di inviare i propri log ad un server Redis, direttamente in formato JSON e di entrare in real-time all’interno della potente catena ELK (ElasticSearch, Logstash e Kibana). La funzionalità è stata scritta da 2ndQuadrant Italia e rilasciata open source, con licenza PostgreSQL.

Infatti, uno degli obiettivi di redislog è quello di permettere a sistemi come Logstash di attingere direttamente da PostgreSQL per il monitoraggio in tempo reale. In una simile architettura, redislog agisce da “mittente” in grado di inviare eventi attraverso un “intermediario” come Redis. Ulteriore dimostrazione che PostgreSQL si integra con tutto e con tutti.

Tornando alla conferenza, sono previsti anche gli immancabili eventi sociali tipici della comunità di PostgreSQL:

• giovedì 22, ore 18:00, la pg_beer. Una birra in compagnia, offerta da Interlogica, uno dei partner dell’evento.

• giovedì 22, ore 20:30 la pg_cena presso il pub Camelot 3.0 in via S. Stefano, 20-22. I biglietti per la cena, dal costo di 17 euro, sono acquistabili su evenbrite.

• venerdì 23, ore 18:00, dopo la conferenza ancora pg_beer, offerta sempre da Interlogica.

Vi aspettiamo numerosi!