Nella puntata precedente, abbiamo introdotto la funzionalità di replica logica aggiunta a PostgreSQL 9.4. Continuiamo a nuotare nel mare di novità che la versione 9.4 porta nel campo Operation, con l’obiettivo di migliorare la gestione di database PostgreSQL per amministratori di sistema e DBA.

pg_prewarm

pg_prewarm è una nuova estensione per risolvere il problema dei rallentamenti post riavvio. In seguito a un riavvio di PostgreSQL, infatti, i buffer sono cancellati e Postgres non è più in grado di ritrovare subito in RAM i dati richiesti. Con pg_prewarm è possibile caricare in memoria una tabella importante immediatamente dopo il riavvio con un semplice

SELECT pg_prewarm('my_table');

In questo modo non sarà più necessario avere un database a regime per avere i dati in cache.

Gestione dei tablespace

Due piccole novità sono state introdotte per semplificare l’uso dei tablespace. La prima è l’introduzione del comando ALTER TABLESPACE … MOVE, che permette di spostare tabelle, indici e viste materializzate da un tablespace a un altro. La seconda è la sintassi CREATE TABLESPACE … WITH … options con cui diventa possibile impostare opzioni del tablespace direttamente in fase di creazione, risparmiando un secondo ALTER TABLESPACE. I due parametri possibili al momento sono seq_page_cost e random_page_cost, che possono essere utili al planner per comprendere quali dischi sono più veloci di altri.

CREATE TABLESPACE new_tblspc LOCATION 'my_dir' WITH random_page_cost = 1;
ALTER TABLESPACE old_tblspc MOVE TABLES TO new_tblspc;

Monitoraggio dell’archiviazione dei WAL

Nel corso del nostro lavoro su Barman in 2ndQuadrant, più volte ci siamo trovati a stimare la produzione di WAL di un server. Per questo, il nostro Gabriele Bartolini ha sviluppato questa patch. Adesso è possibile avere a disposizione una tabella di statistiche sull’attività dell’archiver che mostra il numero di WAL archiviati nel tempo (e, eventualmente, di archiviazioni fallite).

SELECT * FROM pg_stat_archiver;
-[ RECORD 1 ]------+------------------------------
 archived_count     | 4
 last_archived_wal  | 00000001000000000000000B
 last_archived_time | 2014-10-07 08:58:02.258657+00
 failed_count       | 0
 last_failed_wal    |
 last_failed_time   |
 stats_reset        | 2014-10-07 08:51:29.852523+00

Standby ritardati nel tempo

Se uno standby è uno strumento utile nel caso di crash del master, è totalmente inutile nel caso di un errore umano. Una “DROP TABLE” errata da parte dell’amministratore e diventa immediatamente necessaria una Point In Time Recovery. La possibilità di avere un server in replica che applichi i cambiamenti con un certo ritardo concede invece un intervallo di tempo per fermare la replica, evitando che l’errore si propaghi.

Per impostare ad esempio uno standby in ritardo di almeno un’ora, basta impostare nel recovery.conf:

min_recovery_apply_delay = 1h

Modifica della configurazione

Un altro nuovo comando introdotto nella 9.4 per rendere più comodo lavorare con PostgreSQL è ALTER SYSTEM. Adesso è diventato possibile cambiare il file postgresql.conf da dentro una connessione SQL. Con le sole eccezioni dei parametri impostabili in fase di compilazione e della PGDATA, gli altri possono essere modificati come dell’esempio successivo:

ALTER SYSTEM SET wal_level = hot_standby;

I nuovi valori saranno scritti nel file postgresql.auto.conf. Resta necessario eseguire un reload o un riavvio per i parametri che lo richiedono.

Performance dei WAL

Per quanto riguarda i WAL, non ci sono comandi nuovi, ma miglioramenti delle prestazioni. È stata ridotta la lock contention per le operazioni di insert nei WAL. Inoltre, è stata diminuita la dimensione dei WAL record generati dalle UPDATE. In questo modo sarà possibile effettuare più scritture impiegando minore I/O.

Conclusioni

Per noi amministratori di sistemi Linux e DBA, PostgreSQL 9.4 migliora ulteriormente la gestione ordinaria di database in continuità operativa. Inoltre, pone le basi per aprire nuovi orizzonti in ambito architetturale, fra cui la replica multi-master. Grazie alla replica logica, infatti, vedremo sicuramente gli strumenti di replica basati su trigger (come Londiste, Slony, Bucardo) aggiungere il supporto alla decodifica degli eventi direttamente da replication slot logici, rendendo molto più snella la gestione della replica. Se siete interessati, potete seguire il nostro blog con l’articolo di Giuseppe sulle novità per sviluppatori. A presto!