PostgreSQL Database: Server Consolidation. Master & Hot Standby

PostgreSQL : replica in 5 minuti tra server master e slave.
del 31/10/13 - di Andrea Bazzanini

* Introduzione

Oggi giorno i database sono alla base della maggior parte delle applicazione che usiamo tutti i giorni. Dai siti web come questo a grossi gestionali. Dietro ogni programma quasi sempre le informazioni vengono archiviate su Database. Le performance delle applicazione vengono notevolmente influite dalle performance dei database server. E ovviamente la mancanza del back-end database fa fermare l'intera infrastruttura. Avere una solida struttura database aiuta a ridurre i tempi fermo dell'impianto e aumenta le performance delle applicazioni. Uno dei datase piu diffuso e' di sicuro PostgreSQL che si pone come concorrente economico di Oracle. PostgreSQL implementa dei servizi semplici per ridurre i tempi di fermo e sopratutto di ridurre il piu possibile il disastro totale ! Qui sotto vedremo come implementare un semplice servizio di replica , che permettera di avere un Database chiamato Master online e un secondo server di replica, allineato con i database master.

* Preparazione

Prima di procedere, dovete avere due server database pronti per l'uso. I due server possono anche girare sullo stesso hardware. Quindi fate riferimento a come configurare a questo link. Se avete compilato Postgres correttamente possiamo far partire i due server database.

Prepariamo la struttura dove andranno messi i nostri database. E cambiamo l'owner da root a postgres



mkdir -p /postgres/main

mkdir -p /postrgre/slave

mkdir -p /postgres/archive

chow -R postgres.postgres /postgres

chmod 700 /postgres/main

chmod 700 /postgres/slave

Cambiamo utente e da root passiamo a postgres per creare i due database server.



su - postgres

cd /custom/postgres/bin

./pg_ctl initdb -D /postgres/main

./pg_ctl initdb -D /postgres/slave

Modificate la configurazione di postgres.conf del server slave e cambiate la porta come indicato qui sotto. Girando sulla stessa macchina la porta TCP deve essere diversa dal database principale..



nano /postgres/slave/postgres.conf

port = 5433

Ora avviate i due processi di potgresql, specificando anche dove ridirigere l'output. Avrete cosi modi di poter controllare i log dei due server.



./pg_ctl start  -D /postgres/main -l /postgres/main.log

./pg_ctl start  -D /postgres/slave -l /postgres/slave.log

* Preparazione del server Master

Prepariamo il server Master per creare i file "WAL" e scriverli in un folder specifico. Per fare questo vanno modificati alcuni parametri del file di configurazione. Sostituite nel file di configurazione del server master i seguenti parametri:



nano /postgres/main/postgres.conf



wal_level = hot_standby

archive_mode = on

archive_command = 'test ! -f /postgres/archive/%f && cp %p /postgres/archive/%f'

Al riavvio di postgres, verranno creati nel folder /postgres/archive i log con le modifiche apportate ai dati. Fate ripartire postgres cosi che venga riletta la configurazione e create un vostro database di test. Nel database metteteci qualche dato.



./pg_ctl stop  -D /postgres/main

./pg_ctl start  -D /postgres/main -l /postgres/main.log

Postgres da ora in poi iniziera a salvare i log in /postgres/archive. Scrivete ancora qualche dato nel vostro db di prova. Qualche milione di righe va piu che bene! Il vostro server Master e ora pronto.

* Preparazione del server Hot Standby

Fermiamo il database slave avviato in precedenza.

 

./pg_ctl stop  -D /postgres/slave

Creiamo una copia del database master. Per poter eseguire la copia a caldo senza interrompere il servizio del DB seguite i comandi qui sotto. Fate attenzione : con la copia del server master avete anche sovrascritto la configurazione del server slave. Poco male, dovete solo rimettere a posto la porta TCP utilizzata.



./psql postgres -c "select pg_start_backup('backup')"

cp -pr /postgres/main /postgres/slave

./psql postgres -c "select pg_stop_backup()"

rm /postgres/slave/postmaster.pid

Ora abbiamo una copia del nostro database principale. Configuriamo il database per far si che legga i famosi WAL file all'avvio e rimanga in attesa di quelli successivi. COsi facendo avremo un database sempre allineato con il server master, ma in sola lettura. Nel folder del databe slave create il file di recovery.



nano /postgres/slave/recovery.conf

Inserite le seguenti righe all'interno del file.



# Avvia Postgres in modalita StandBy. Il server diventa ReadOnly

standby_mode = on



# Comando che ripristina i WAL files restore_command =

'cp -i /postgres/archivedir/%f %p'



# I WAL files applicati vengono rimossi

# archive_cleanup_command = 'pg_archivecleanup /postgres/archivedir %r'

Ora avviamo postgres. Il server slave dovrebbe iniziare ad applicare i file WAL che trova nel percorso /postgres/archivedir. Qui sotto torvate un pezzo di log. Una volta importato il WAL file, postgres iniziera a cercare il file successivo. Appena viene scritto il file dal server master, questo verra importato dal server slave.



cp: cannot stat `/postgres/archivedir/000000010000001D000000F1': No such file or directory

user=,db=,2013-10-02 00:24:51 CEST, LOG: restored log file "000000010000001D000000F1" from archive

cp: cannot stat `/postgres/archivedir/000000010000001D000000F2': No such file or directory

user=,db=,2013-10-02 00:24:51 CEST, LOG: unexpected pageaddr 1D/D1000000 in log file 29, segment 242, offset 0

cp: cannot stat `/postgres/archivedir/000000010000001D000000F2': No such file or directory

* Da questo momento tutte le modifiche apportate al server master daranno importata dal server slave. Il server slave è anche utilizzabile come server di sola lettura.

Replication