Le ultime novità sono che il software è stato presentato lunedì a Stoccarda in occasione del PGDay europeo, e la risposta del pubblico, indubbiamente positiva, mi ha indotto a pubblicare il codice su GitHub, con il nome di pgChess.

Il PGDay italiano 2010 è organizzato dall’Associazione ITPUG.

Il convegno sarà aperto dal keynote speech di Simon Riggs, seguito da un’ampia selezione di interventi di Gabriele Bartolini, Oleg Bartunov, Paolo Cavallini, Luca Ferrari, David Fetter, Jonathan S. Katz, Bruce Momjian, Enrico Pirozzi e Daniele Varrazzo.

Saranno illustrati casi d’uso di PostgreSQL da parte del CNR, del Comune di Prato e del Sistema Bibliotecario Vimercatese.

I partecipanti potranno inoltre partecipare a dei tutorial, compresi nella registrazione al convegno.

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

Nello specifico, le nuove funzionalità affrontate in questa sede sono: trigger su colonna e trigger con condizione (WHEN).

Una piccola premessa per coloro che non sono ancora familiari con PostgreSQL: Postgres fornisce il supporto per i trigger sin dalla versione 6.2 (1997).

I trigger su colonna sono attivati soltanto quando una specifica colonna è aggiornata in modo esplicito con una operazione di UPDATE. Permettono pertanto di evitare l’utilizzo di condizioni logiche e operazioni di confronto all’interno del codice delle funzioni trigger.

Ad esempio:

CREATE TRIGGER trigger_aggiorna_col1
BEFORE UPDATE OF col1 ON tabella1
FOR EACH ROW EXECUTE PROCEDURE aggiorna_col1();

Il trigger appena creato viene creato soltanto quando la colonna col1 della tabella tabella1 viene aggiornato, invocando la funzione speciale di tipo trigger aggiorna_col1().

È importante notare che i trigger di colonna non vengono eseguiti se le colonne sono impostate al valore di DEFAULT. L’aggiunta del trigger su colonna va a colmare una lacuna di PostgreSQL rispetto allo standard SQL:2003.

I trigger con condizione, detti anche trigger WHEN, permettono di definire condizioni semplici al solo verificarsi delle quali un determinato trigger viene eseguito. Questa funzionalità completa il tentativo da parte degli sviluppatori di PostgreSQL di limitare l’utilizzo di blocchi condizionali di tipo IF ... THEN all’interno delle procedure trigger, riducendo notevolmente il numero di trigger in esecuzione e conseguentemente il carico di CPU sul server del database.

Ad esempio, il trigger sottostante esegue il controllo sul bilancio di un conto corrente soltanto in caso di modifica del bilancio stesso:

CREATE TRIGGER check_update
BEFORE UPDATE ON accounts
FOR EACH ROW
WHEN (OLD.balance IS DISTINCT FROM NEW.balance)
EXECUTE PROCEDURE check_account_update();

Il seguente esempio invece scriverà nel log un aggiornamento di riga soltanto nel caso di modifica della riga stessa. Questo caso è molto utile in framework e applicazioni che utilizzano ORM, che potrebbero tentare operazioni di modifica anche per righe non realmente modificate:

 CREATE TRIGGER log_update
AFTER UPDATE ON accounts
FOR EACH ROW
WHEN (OLD.* IS DISTINCT FROM NEW.*)
EXECUTE PROCEDURE log_account_update();

Le possibilità sono pressoché infinite. Potrebbe ad esempio essere opportuno ignorare l’aggiornamento in caso di assenza di modifiche:

CREATE TRIGGER log_update
AFTER UPDATE ON accounts
FOR EACH ROW
WHEN (OLD.* IS NOT DISTINCT FROM NEW.*)
EXECUTE PROCEDURE no_op();

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.

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.