PostgreSQL 9.0, un tour sulle novità: parte 2, Streaming Replication

Prosegue con questo articolo su Streaming Replication la mini-serie dedicata alle novità principali di PostgreSQL 9, dopo avere analizzato Hot Standby.

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.