Postgres ripristina la replica, conflitto temporale


1

Ho un database postgres (versione 9.4) con replica streaming (master, configurazione slave). Consente di chiamare il master db A e lo slave db B.

Il server che esegue A ha avuto esito negativo e abbiamo dovuto eseguire una commutazione, in cui abbiamo promosso B come nuovo master. Fino ad ora va tutto bene e funziona bene.

Ora ho ripristinato il server guasto e voglio impostare di nuovo la replica in modo che A possa essere il nuovo slave. Quindi, prendo un backup da B, lo metto nel server A, configuro il file di ripristino e lo avvio. Il problema qui è che non funziona più, perché dice che sono in due diverse linee temporali.

Ecco i messaggi di A (nuovo slave):

2015-10-30 14:28:04 LOG:  database system was shut down in recovery at 2015-10-30 14:27:28 CET 
2015-10-30 14:28:04 LOG:  entering standby mode 
2015-10-30 14:28:04 LOG:  redo starts at 1A/5802B1A8 
2015-10-30 14:28:04 LOG:  consistent recovery state reached at 1A/581FA248 
2015-10-30 14:28:04 LOG:  record with zero length at 1A/581FA248 
2015-10-30 14:28:04 LOG:  database system is ready to accept read only connections 
2015-10-30 14:28:05 LOG:  started streaming WAL from primary at 1A/58000000 on timeline 2 
2015-10-30 14:28:07 ERROR:  requested starting point 19/FE000000 on timeline 1 is not in this server's history 
2015-10-30 14:28:07 DETAIL:  This server's history forked from timeline 1 at 19/FDCF9BA0. 
2015-10-30 14:28:12 ERROR:  requested starting point 19/FE000000 on timeline 1 is not in this server's history 
2015-10-30 14:28:12 DETAIL:  This server's history forked from timeline 1 at 19/FDCF9BA0.

il mio file di recupero ha il seguente aspetto:

standby_mode = 'on'
primary_conninfo = 'host=serverB port=5432 user=replication-user'
restore_command = 'copy "Z:\\pg_xlog\\%f" "%p"'
archive_cleanup_command = '"C:\\Program Files\\PostgreSQL\\9.4\\bin\\pg_archivecleanup" "Z:\\pg_xlog" "%r"'
trigger_file = 'Z:\\trigger\\pgsql.trigger.sekasto021'
recovery_target_timeline = 'latest'

Googling Ho trovato quasi la stessa domanda Qui ma senza risposte. Trovato una pagina da Michael Paquier chi descrive cosa mi sta succedendo (anche se dice che non è un problema dalla versione 9.3). Lui dice:

FATAL:  timeline 2 of the primary does not match recovery target timeline 1

Questo può essere risolto solo copiando i segmenti WAL dal master   nodo o utilizzando un archivio WAL.

Ma purtroppo non so cosa intenda copiando i segmenti wal dal master usando l'archivio a parete.

Qualsiasi aiuto / guida è ben accetto. Grazie

Aggiornamento: ho pubblicato questa domanda su StackOverflow e gli è stato chiesto di inserirlo qui


Risposte:


0

Ora ho ripristinato il server guasto e voglio impostare di nuovo la replica in modo che A possa essere il nuovo slave. Quindi, prendo un backup da B, lo metto nel server A, configuro il file di ripristino e lo avvio. Il problema qui è che non funziona più, perché dice che sono in due diverse linee temporali.

Quindi non hai eseguito correttamente il backup da B. Sembra dai registri come si sta tentando di avviare il vecchia copia di A come una replica di B. Ciò non funzionerà.

È necessario rimuovere / rinominare la vecchia directory dei dati da A. Quindi utilizzare pg_basebackup fare un nuovo backup di B.

(Ci sono altri modi - vedi il manuale - ma questo è il più semplice e facile da ottenere correttamente).

Il problema con la replica di streaming dopo le opzioni della timeline non è correlato al problema corrente.


Grazie, grazie, grazie. Il mio backup non era corretto. Stavo eseguendo il backup del server B correttamente, ma dall'altro server ho confuso le posizioni e stavo copiando un backup da un altro database replicato e questo è il motivo per cui le timeline non corrispondevano.
Keyjote

0

Come accennato da Craig Ringer, ho fatto un nuovo backup e controllato e dopo aver configurato il server slave ha funzionato.

Ma mentre stavo facendo tutto ciò, ricordavo anche che c'era un vecchio server che era anche uno schiavo del vecchio master db (A) (quel server non avrebbe dovuto essere in esecuzione ed è per questo che inizialmente non ci pensavo) . Ad ogni modo, dopo aver portato giù il vecchio schiavo e fatto di nuovo il backup e il ripristino, ha semplicemente funzionato.

Come ho detto, inizialmente pensavo che fosse a causa di un brutto backup, ma alla fine si è trattato di un messaggio di errore prodotto da un terzo server (secondo slave db). Solo per dimostrare il mio punto ho avviato il vecchio server e ho ricevuto nuovamente i messaggi di errore.

2015-10-31 10:26:37 CET ERROR:  requested starting point 19/FE000000 on timeline 1 is not in this server's history
2015-10-31 10:26:37 CET DETAIL:  This server's history forked from timeline 1 at 19/FDCF9BA0.

Quindi, sembra che la replica stia funzionando da sola ma questi messaggi di errore fatti da una seconda replica mi hanno buttato fuori.

Ancora una volta, grazie Craig per l'aiuto.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.