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

PostgreSQL Training

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

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

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

Barman Training

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

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

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

Bi-Directional Replication (BDR) Training

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

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

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

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

Iscriviti al corso sulla BDR!

One-to-One

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

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

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

2ndQuadrant ed il Kanban

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

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

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

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

Oltre la conferenza: Let’s Network!

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

Vi aspettiamo numerosi il 12 e 13 maggio a Milano!

È da notare che, in seguito a una modifica nel catalogo di sistema, è necessario effettuare di nuovo initdb e ricaricare i database in caso di aggiornamento dalle versioni Beta precedenti. Cogliamo l’occasione per incoraggiare gli utenti a sfruttare questa opportunità per testare il funzionamento di pg_upgrade per l’aggiornamento da una versione 9.0 beta o da una versione precedente alla 9.0. Vi preghiamo di riportare i risultati ottenuti.

Se sei in grado di aiutare nella fase di beta testing, sei pregato di visitare la pagina con le istruzioni sul Beta testing di PostreSQL.

Nessun cambiamento nei comandi, nelle interfacce e nelle API sono attesi fra questa release e la versione finale. Le applicazioni che verranno messe in produzione con la versione 9.0 di PostgreSQL possono (e dovrebbero) essere provate con la versione 9.0rc1. Il rilascio di ulteriori versioni release candidate prima della versione finale dipenderà dal feedback degli utenti e dai bug che saranno segnalati dagli utilizzatori.

Il codice sorgente, insieme a installer binari per diverse piattaforme, sono a disposizione dal sito di PostgreSQL:

• Sorgente
• One-Click Installer, comprendente binari Win64
• Binari per altre piattaforme
• Release Note
• Partecipare alla fase di test

Streaming replication (che potrebbe essere tradotta in replica a flusso continuo) è un’altra funzionalità, complementare a Hot Standby, che permette a PostgreSQL di fare un grande balzo in avanti.

Nonostante infatti ci siano già soluzioni di terze parti per la replica di database PostgreSQL in grado di soddisfare esigenze specifiche, la nuova release porterà una versione semplice, solida e soprattutto integrata per la replica master-slave che sarà molto probabilmente usata di default nelle installazioni in alta disponibilità (high availability, con l’accoppiata Hot Standby e Streaming replication).

L’obiettivo di streaming replication è quello di migliorare il meccanismo di archiviazione, rendendolo il più continuo possibile (senza dover attendere la spedizione dei file di log). I server in standby possono adesso connettersi al server primario (master) in modo da farsi spedire le informazioni necessarie dal Write Ahead Log (WAL).

Ciò avviene sulla base non di file interi (WAL segments, tipici della replica asincrona basata su log shipping), ma in termini di singoli record per il WAL (che possono essere considerati dei veri e propri "frammenti" di questi file).

Streaming Replication è un meccanismo asincrono e il server in standby non è garantito essere sempre in pari e aggiornato con il master. A differenza di altri metodi di replica però, il ritardo è molto leggero e può anche essere piccolo come una singola transazione (anche se ciò dipende dalla velocità della rete, dall’attività del database e dai settaggi di hot standby). Inoltre, il carico sul server master è minimo, garantendo pertanto il supporto di decine di server slave.

I database primario e standby sono identici per quanto riguarda i dati memorizzati a basso livello (a dire il vero sono quasi identici, ma non vi preoccupate se i file di dati non hanno le stesse checksum).

Per abilitare Streaming Replication, wal_level dovrebbe essere impostato a 'archive' o 'hot standby' in modo da attivare l’archiviazione continua.

Sul primario, nel file postgresql.conf:

max_wal_senders = 5 # Numero massimo di processi 'wal_senders'
# responsabili della gestione di una connessione
# con un server standby
wal_keep_segments = 10 # Numero di segmenti (file) WAL che il master
# deve tenere per emergenza all'interno di pg_xlog
# nel caso in cui il server in streaming replication
# rimanga indietro e necessiti di recuperare il file WAL
# per scopi di replica
# wal_level
wal_level=hot_standby # attiva anche hot standby e le connessioni in lettura
#wal_level=archive # abilita invece sola replica, senza hot standby

Sul/sui server in standby, all’interno del file recovery.conf:

standby_mode = 'on'
# Stringa di connessione per raggiungere il database primario
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'

Sul/sui server in standby, all’interno del file postgresql.conf:

# wal_level (stesso valore impostato sul master, in caso di failover)
wal_level=hot_standby # attiva anche hot standby e le connessioni in lettura
#wal_level=archive # abilita invece sola replica, senza hot standby
hot_standby=on/off # attivare hot standby

All’interno del file pg_hba.conf, deve esserci una entry per l’abilitazione delle connessioni di replica. Il database fasullo è replication e l’utente disegnato dovrebbe essere superuser. Fate attenzione a non allargare l’accesso a questo utente in quanto molte informazioni privilegiate e protette possono essere estratte dai record WAL.

Sul PostgreSQL primario, nel file pg_hba.conf, inserire:

host replication foo 192.168.1.100/32 md5

Allo stesso modo di Hot Standby anche questa funzionalità è ricca e complessa. E’ consigliato leggere la documentazione di PostgreSQL. Inoltre, è ottima prassi mettere in pratica procedure di test per il failover e lo switchover prima di andare in produzione.

Una cosa da tenere presente è che si può utilizzare congiuntamente Hot Standby e Streaming Replication. Ciò significa che è possibile ottenere una quasi immediata replica sui nodi standby ed eseguire query su di essi (come query di reportistica). Non è da escludere infine un utilizzo combinato delle soluzioni: un server in replica può essere soltanto Hot Standby (con log shipping) e un altro con solo Streaming Replication (senza accettare query in sola lettura).

Nota: Ricordo che questo speciale sulla versione 9 è fortemente ispirato dal wiki di PostgreSQL e in molti casi ne rappresenta una fedele traduzione in lingua italiana.

Alcuni cambiamenti significativi sono stati introdotti nella versione Beta2, che richiederà ad alcune applicazioni di eseguire di nuovo il test per la 9.0. Questi includono:

• Correzioni per questioni di sicurezza, come nell’annuncio del 17 maggio scorso
• Modifiche alla sintassi per parametri nominali
• aggiunta di pg_upgrade ai moduli addizionali (contrib)
• Modifiche a parametri e opzioni nel file recovery.conf
• diverse correzioni in seguito a segnalazioni riportati con la versione Beta1

E’ da notare che, in seguito a una modifica nel catalogo di sistema, è necessario effettuare di nuovo initdb e ricaricare i database in caso di aggiornamento dalla versione Beta1. Cogliamo l’occasione per incoraggiare gli utenti a sfruttare questa opportunità per testare il funzionamento di pg_upgrade per l’aggiornamento dalla Beta1 o da una versione precedente alla 9.0. Vi preghiamo di riportare i risultati ottenuti.

Se sei in grado di aiutare nella fase di beta testing, sei pregato di visitare la pagina con le istruzioni sul Beta testing di PostreSQL.

Le versioni beta non sono stabili per natura e non dovrebbero mai essere utilizzate in ambienti di produzione; sono esclusivamente ad uso di test. Altre versioni beta oppure una versione di tipo "release candidate" saranno disponibili fra alcune settimane.

Il codice sorgente, insieme a installer binari per diverse piattaforme, sono a disposizione dal sito di PostgreSQL:

• Sorgente
• One-Click Installer, comprendente binari Win64
• Binari per altre piattaforme
• Release Note
• Partecipare alla fase di test