Configurazione Master - Replica (streaming) |
  
|
Configurazione Master - Replica (streaming) |
|
Questa configurazione server per avere un Server (Attenzione Tutto il server non solo un DB) Master ed uno (o più) Server Replica (slave) in HotStandby.
Il fatto che la replica sia in Hot Standby permette di eseguire query di sola lettura sul server Replica
Ci sono vari metodi per la replica: quello scelto è lo streming replication tramite il quale le transazioni eseguite sul master vengono distribuite anche agli slave (in realtà è lo slave che si occupa di andare a recuperarsele attingendo a processi sul master (i wal_senders) che eseguono la distribuzione.
Configurazione streaming replication
1)Sul master, nel postgresql.conf
a.listen_addresses = ‘*’
b.wal_level = hot_standby
c.max_wal_senders = 6
d.poi occorre settare un paio di valori "accoppiati" in funzione del carico che si presume per il server:
# light load 500MB
checkpoint_segments = 8
wal_keep_segments = 8
# moderately busy
checkpoint_segments = 16
wal_keep_segments = 32
# busy server
checkpoint_segments = 64
wal_keep_segments = 128
2)Sul master, nel pg_hba.conf
a.host replication all nnn.nnn.nnn.nnn/32 md5
dove nnn.nnn.nnn.nnn = ip dell’ultimo hop di accesso al server master (quindi se per esempio il server del master è all’interno di una rete firewallata e lo slave è fuori da tale rete allora quello sarà l’indirizzo del firewall/gateway del server master)
3)Sullo slave, nel postgresql.conf
a.hot_standby = on
b.verificare che il parametro di max_connections sia uguale a quello del master
4)Sullo slave, creare nella data directory del server creare un file recovery.conf in cui metto:
a.standby_mode = ‘on’
b.primary_conninfo = ‘host=mmm.mmm.mmm.mmm port=ppppp user=myuser password=pwd’
dove mmm.mmm.mmm.mmm= ip del server master
ppppp=porta del server master
myuser=utente di connessione
pwd=password dell’utente di connessione
c.trigger_file = 'fullpath_to_failover_file'
es. trigger_file = ‘C:\PostgreSQL\data\failover.txt’
in questo modo quando lo slave vede presente il file qui indicato automaticamente si autopromuove a master ed abilita le scritture
5)a questo punto occorre (*1) stoppare il database sul master e sullo slave
6)zippare la data directory del master (esclusi postgresql.conf e la cartella pg_xlog) e copiarla sullo slave
7)verificare che sullo slave la data directory abbia i diritti corretti (se si rinomina la data directory originale potrebbe perderli) e riavviare prima lo slave poi il master: sul log dello slave dovremmo trovare i messaggi di connessione al master.
(*1) se il server era già presente occorre restartare il server con un livello di log ad hot_standby altrimenti lo slave non riesce a salire
Il master non è consigliabile startarlo prima dello slave perchè altrimenti all'avvio dello slave questo cercherà di recuperare le transazioni non scritte richedendo al server un determinato set di checkpoint_segments del WAL, ma se il master li ha già persi per rotazione, lo slave non riuscirà a partire.
Per questo motivo sono importanti i settaggi di wal_keep_segment e checkpoint_segments, questi determinano quanto lo slave può "fall back" letteralmente "cadere indietro" rispetto al master. Per non incorrere in perdite sullo slave sarebbe preferibile attivare l'archiving dei segments, ma questo rischia poi di creare una valanaga di spazio occupato sul master.
L'utilizzo di un wal_keep_segment più ampio risulta anche utile a dare un'idea di quanto il server sia busy: se i segment (i file presenti nella data directory del server nella cartella pg_xlog) cartella sono molto ravvicinati come ora e data significa che la rotazione è alta.
Messaggi, sulla replica, del tipo:
•il pageaddr 170/1491E000 nel file di log 368, segmento 31, offset 9560064 non era previsto
non significano problemi sulla replica stessa, ma anzi sono soliti dopo una disconnessione/riconnessione al master,
vedi: https://www.postgresql.org/message-id/5031.1296689542@sss.pgh.pa.us
"unexpected pageaddr" is just one of the standard tests for detecting
end of WAL, so I don't think this is anything to be surprised about.
It looks to me like the standby applied all the WAL it had and then
connected to the master for more.