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.