Come posso risolvere uno slave PostgreSQL 9.3 che non può mantenere il passo con il master?

Question

Abbiamo una configurazione di replica master-slave come segue.

Sul master:

postgresql.conf ha replica configurato come segue (linea commentata tolto per brevità):

max_wal_senders = 1    
wal_keep_segments = 8   

Sul slave:

Stesso postgresql.conf come sul master. recovery.conf assomiglia a questo:

standby_mode = 'on' 
primary_conninfo = 'host=master1 port=5432 user=replication password=replication' 
trigger_file = '/tmp/postgresql.trigger.5432' 

Quando questo è stato inizialmente messa a punto, abbiamo effettuato alcuni test semplici e confermato la replica stava lavorando. Tuttavia, quando abbiamo eseguito il caricamento iniziale dei dati, solo alcuni dati lo hanno reso allo slave.

registro dello schiavo è ora riempito con i messaggi che assomigliano a questo:

< 2015-01-23 23:59:47.241 EST >LOG: started streaming WAL from primary at F/52000000 on timeline 1 
< 2015-01-23 23:59:47.241 EST >FATAL: could not receive data from WAL stream: ERROR: requested WAL segment 000000010000000F00000052 has already been removed 

< 2015-01-23 23:59:52.259 EST >LOG: started streaming WAL from primary at F/52000000 on timeline 1 
< 2015-01-23 23:59:52.260 EST >FATAL: could not receive data from WAL stream: ERROR: requested WAL segment 000000010000000F00000052 has already been removed 

< 2015-01-23 23:59:57.270 EST >LOG: started streaming WAL from primary at F/52000000 on timeline 1 
< 2015-01-23 23:59:57.270 EST >FATAL: could not receive data from WAL stream: ERROR: requested WAL segment 000000010000000F00000052 has already been removed 

Dopo alcune analisi e aiutano sul canale #postgresql IRC, sono giunto alla conclusione che lo schiavo non riesce a tenere il passo con il maestro. La mia soluzione proposta è la seguente.

Sul master:

1. Set max_wal_senders=5
2. Set wal_keep_segments=4000. Sì, lo so che è molto alto, ma mi piacerebbe monitorare la situazione e vedere cosa succede. Ho spazio sul maestro.

Sul slave:

1. file di configurazione Salva nella directory di dati (vale a dire pg_hba.conf pg_ident.conf postgresql.conf recovery.conf)
2. Cancella la directory dei dati (rm -rf /var/lib/pgsql/9.3/data/*). Questo sembra essere richiesto da pg_basebackup.
3. eseguire il seguente comando: pg_basebackup -h master -D /var/lib/pgsql/9.3/data --username=replication --password

Mi sto perdendo qualcosa? C'è un modo migliore per aggiornare lo slave senza dover ricaricare tutti i dati?

Qualsiasi aiuto è molto apprezzato.

Answer 1

Le due opzioni importanti per affrontare il WAL per streaming replication:

• wal_keep_segments dovrebbe essere abbastanza alto da permettere uno schiavo di raggiungere, dopo un ritardo ragionevole (ad esempio, il volume alto aggiornamento, schiava di essere non in linea, eccetera...).

• archive_mode consente l'archiviazione WAL che può essere utilizzata per ripristinare file precedenti a wal_keep_segments. I server slave necessitano semplicemente di un metodo per recuperare i segmenti WAL. NFS è il metodo più semplice, ma qualsiasi cosa, da scp a http e ai nastri, funzionerà a patto che possa essere programmata.

  # on master 
  archive_mode = on 
  archive_command = 'cp %p /path_to/archive/%f' 
  
  # on slave 
  restore_command = 'cp /path_to/archive/%f "%p"' 
  

  Quando lo schiavo non può tirare il segmento WAL direttamente dal master, tenterà di utilizzare la restore_command per caricarlo. È possibile configurare lo slave per rimuovere automaticamente i segmenti utilizzando l'impostazione archive_cleanup_command.

Se lo slave viene a una situazione in cui il segmento successivo WAL di cui ha bisogno è presente sia per il master e l'archivio, non ci sarà modo di recuperare in modo coerente il database. L'opzione ragionevole solo è quindi per pulire il server e ricominciare da un nuovo pg_basebackup.

Answer 2

Come Ben Grimm ha suggerito nei commenti, si tratta di assicurarsi di impostare segmenti al valore massimo possibile per consentire allo slave di raggiungere.