Postgres Wiederherstellen der Replikation, Timeline-Konflikt

4482
Keyjote

Ich habe eine Postgres-Datenbank (Version 9.4) mit Streaming-Replikation (Master, Slave-Konfiguration). Rufen wir Master-DB A und Slave-DB B auf.

Der Server, auf dem A ausgeführt wird, ist fehlgeschlagen, und wir mussten eine Umschaltung vornehmen, bei der wir B zum neuen Master beförderten. Bis jetzt ist alles gut und funktioniert gut.

Jetzt habe ich den defekten Server wiederhergestellt und möchte die Replikation erneut einrichten, damit A der neue Slave sein kann. Also nehme ich ein Backup von B, lege es in Server A, erstelle die Wiederherstellungsdatei und starte sie. Das Problem hier ist, dass es nicht mehr wirklich funktioniert, da es sich um zwei verschiedene Zeitreihen handelt.

Hier sind die Nachrichten von A (neuer 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. 

meine Wiederherstellungsdatei sieht folgendermaßen aus:

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' 

Googeln Ich habe hier fast dieselbe Frage gefunden, aber keine Antworten. Ich habe eine Seite von Michael Paquier gefunden, der beschreibt, was mit mir passiert (obwohl er sagt, dass es keine Ausgabe von Version 9.3 ist). Er sagt:

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

Dies kann nur durch Kopieren der WAL-Segmente vom Masterknoten oder durch Verwendung eines WAL-Archivs gelöst werden.

Leider weiß ich nicht, was er bedeutet, wenn er die Wandsegmente mit Hilfe des Wandarchivs vom Master kopiert.

Jede Hilfe / Anleitung wird begrüßt. Vielen Dank

Update: Ich habe diese Frage auf stackoverflow gestellt und wurde gebeten, sie stattdessen hier zu veröffentlichen

1
x-gepostet auf http://stackoverflow.com/q/33437732/398670 Craig Ringer vor 8 Jahren 0

2 Antworten auf die Frage

0
Craig Ringer

Jetzt habe ich den defekten Server wiederhergestellt und möchte die Replikation erneut einrichten, damit A der neue Slave sein kann. Also nehme ich ein Backup von B, lege es in Server A, erstelle die Wiederherstellungsdatei und starte sie. Das Problem hier ist, dass es nicht mehr wirklich funktioniert, da es sich um zwei verschiedene Zeitreihen handelt.

Dann haben Sie die Sicherung von B nicht richtig gemacht. Es sieht aus den Protokollen aus, als würden Sie versuchen, die alte Kopie von A als Replikat von B zu starten . Das wird nicht funktionieren.

Sie müssen das alte Datenverzeichnis von A entfernen / umbenennen. Verwenden Sie dann pg_basebackup, um eine neue Sicherung von B zu erstellen .

(Es gibt andere Möglichkeiten - siehe Handbuch - aber dies ist die einfachste und am einfachsten zu befolgende Methode).

Das Problem bei der Streaming-Replikation nach Zeitleistenänderungen hängt nicht von Ihrem aktuellen Problem ab.

Danke danke danke. Meine Sicherung war falsch. Ich habe den B-Server korrekt gesichert, aber vom anderen Server habe ich die Speicherorte verwechselt und eine Sicherung aus einer anderen replizierten Datenbank kopiert. Deshalb stimmen die Zeitleisten nicht überein. Keyjote vor 8 Jahren 0
0
Keyjote

Wie von Craig Ringer erwähnt, habe ich ein neues Backup erstellt und überprüft, und nachdem ich den Slave-Server eingerichtet hatte, funktionierte er.

Aber während ich all das tat, fiel mir auch ein, dass es einen alten Server gab, der auch ein Sklave der alten Master-Datenbank (A) war (der Server sollte nicht laufen, und deshalb dachte ich zunächst nicht daran). . Wie auch immer, nachdem der alte Sklave heruntergenommen und wieder hergestellt und wiederhergestellt wurde, hat es einfach funktioniert.

Wie ich bereits sagte, dachte ich zunächst, es handele sich um ein fehlerhaftes Backup, aber es wurde eine Fehlermeldung, die von einem dritten Server erzeugt wurde (zweite Slave-Datenbank). Um meinen Standpunkt zu beweisen, habe ich den alten Server gestartet und die Fehlermeldungen erneut erhalten.

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. 

Es scheint also, dass die Replikation ganz alleine funktioniert hat, aber diese Fehlermeldungen, die durch eine zweite Replikation gemacht wurden, haben mich abgestoßen.

Nochmals vielen Dank Craig für die Hilfe.