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!

PostgreSQL 9 comprende il supporto nativo per la replica e una dozzina (e oltre) di nuove funzionalità principali in grado di attirare chiunque, dagli sviluppatori web agli hacker più accaniti.

Un numero così elevato di nuove funzionalità major non si era mai verificato in un singolo rilascio di PostgreSQL. Fra le principali novità, sono degne di citazione:

• Hot standby
• Streaming replication
• In-place upgrade
• Supporto a 64-bit per Windows
• Gestione di massa per i privilegi
• Blocchi anonimi e parametri nominali nella chiamata a stored procedure
• Nuove funzioni finestra e aggregati ordinati

… e molte altre ancora.

Per un elenco più dettagliato delle oltre 200 aggiunte e migliorie di questa versione, portata avanti da oltre un centinaio di sviluppatori, si prega di far riferimento alle note di rilascio.

"Questo genere di funzionalità aggiuntive continuano spiegano il perché attività tecnologiche di tipo mission critical possano contare sulla potenza, flessibilità e robustezza di PostgreSQL" Ram Mohan, CTO di Afilias.

Ulteriori informazioni su PostgreSQL 9.0:

• Note di rilascio (in inglese)
• Presskit
• Guida alla 9.0 (in inglese)

Scarica PostgreSQL 9.0 adesso:

• Pagina principale per il download
• Sorgenti
• Pacchetti binari
• One-Click Installer, comprendente binari per Windows

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.

Lo speciale è fortemente ispirato dal wiki di PostgreSQL e in molti casi ne rappresenta una traduzione in lingua italiana.

Hot Standby è, insieme a Streaming Replication, una delle due principali nuove funzionalità che rendono la versione 9.0 una vera e propria pietra miliare nell’evoluzione di PostgreSQL. Esse costituiscono inoltre la motivazione per cui è stato deciso di riservare un’intero numero di versione per questa nuova release: 9.0 (non 8.5).

Hot Standby permette ad un utente di creare un database di tipo standby, ovvero una seconda istanza di database (di solito su un server separato) che replica il log binario del server primario e al tempo stesso si rende disponibile per query in sola lettura (read-only). Questa funzionalità è molto simile a soluzioni proprietarie come DataGuard di Oracle.

Durante l’esecuzione di query read-only, il database in standby replica le modifiche che arrivano dal database primario in forma binaria e decide se queste modifiche sono in qualche modo in conflitto con le interrogazioni in sola lettura. In particolare, il server standby decide se mettere in pausa la replica oppure interrompere le query.

La funzionalità di Hot Standby ha reso necessaria l’aggiunta di alcune informazioni nel log delle transazioni (WAL) di PostgreSQL e di un meccanismo di risoluzione dei conflitti.

Abilitare Hot Standby è un procedimento molto semplice. È sufficiente impostare il database primario nel seguente modo, aggiungendo a postgresql.conf:

wal_level = 'hot_standby' # Aggiunge le informazioni necessarie nei WAL
# vacuum_defer_cleanup_age # Potresti aver bisogno di impostare questo attributo
# Per maggiori informazioni, vedi la documentazione

A questo punto, occorre creare un database di standby, nello stesso identico modo in cui in precedenza venivano creati i database in warm standby, ovvero:

• pg_start_backup sul primario;
• copia dei file binari;
• pg_stop_backup sul primario;
• copia dei log e del backup sul server di standby.

Per abilitare Hot Standby sul server di replica, aggiungere a postgresql.conf:

hot_standby = on
max_standby_delay = 30s # -1= sempre in attesa, 0= mai in attesa
# altrimenti attendi questi secondi

Quindi utilizzare un programma come pg_standby sul nodo secondario al fine di abilitare il ripristino continuo (replay) dei log: questo comportamento può essere configurato nel file recovery.conf.

Il parametro max_standby_delay determina il comportamento del database di standby nel caso in cui si verifichi un conflitto fra il replay e le interrogazioni in sola lettura. In questa situazione, il nodo standby rimarrà indietro rispetto al primario al massimo max_standby_delay secondi prima di interrompere la query sulla replica.

Prima di mettere le mani su HotStandby è consigliato vivamente leggere la documentazione di PostgreSQL. L’apprendimento di parametri di configurazione come max_standby_delay e vacuum_defer_cleanup_age richiede infatti un po’ di pratica.

È infine da ricordare che, in modo simile a warm standby, possono esserci più istanze di replica.

Non resta pertanto che scaricare PostgreSQL 9 e provare sulla propria pelle questo meccanismo robusto e affidabile per la replica master slave. Nel prossimo articolo entreremo nel dettaglio dell’altra novità fondamentale di PostgreSQL 9: Streaming Replication.