PostgreSQL Replikation: Slave-Server startet nicht mehr

Hallo zusammen.
Habe heute versucht Replikation mit PostgreSQL zu realisieren und das hat auch irgendwie funktioniert :slight_smile:
Nach dem erfolgreichen Test(durch Insert und Delete) der Replikation habe ich den PostgreSQl-Dienst auf dem Primär-Server beendet um Failover zu simulieren.
Im Trigger-Verzeichnis auf dem Standby-Server habe ich eine Triggerdatei erstellt, damit die Replikation auf dem Standby-Server beendet wird.
Die Triggerdatei wurde danach aus dem Verzeichnis gelöscht.
Die Recovery.conf wurde in recover.done umbenannt.

2013-09-20 10:50:17 CEST LOG: Triggerdatei gefunden: C:\stopreplication\standby.txt
2013-09-20 10:50:17 CEST LOG: Redo fertig bei 0/23000028
2013-09-20 10:50:17 CEST LOG: letzte vollständige Transaktion war bei Logzeit 2013-09-20 10:00:15.949+02
2013-09-20 10:50:17 CEST LOG: gewählte neue Zeitleisten-ID: 2
2013-09-20 10:50:17 CEST LOG: Wiederherstellung aus Archiv abgeschlossen
2013-09-20 10:50:17 CEST LOG: Datenbanksystem ist bereit, um Verbindungen anzunehmen
2013-09-20 10:50:17 CEST LOG: Autovacuum-Launcher startet

Mein nächster Schritt war den Standby-Server wieder in Replikationszustand zu bringen.
Ich habe die recovery.done in recovery.conf umbenannt und versucht den PostgreSQl-Dienst neu zustarten.
Beim Neustarten kamm diese Fehlermeldung.
Was kann das sein und was habe ich falsch gemacht?

2013-09-20 10:56:24 CEST LOG: Datenbanksystem wurde am 2013-09-20 10:56:22 CEST heruntergefahren
2013-09-20 10:56:24 CEST LOG: Standby-Modus eingeschaltet
2013-09-20 10:56:24 CEST WARNUNG: WAL wurde mit wal_level=minimal erzeugt, eventuell fehlen Daten
2013-09-20 10:56:24 CEST TIPP: Das passiert, wenn vorübergehend wal_level=minimal gesetzt wurde, ohne ein neues Base-Backup zu erzeugen.
2013-09-20 10:56:24 CEST FATAL: Hot Standby ist nicht möglich, weil wal_level auf dem Masterserver nicht auf „hot_standby“ gesetzt wurde
2013-09-20 10:56:24 CEST TIPP: Setzen Sie entweder wal_level auf „hot_standby“ auf dem Master oder schalten Sie hot_standby hier aus.
2013-09-20 10:56:24 CEST LOG: Startprozess (PID 3508) beendete mit Status 1
2013-09-20 10:56:24 CEST LOG: Serverstart abgebrochen wegen Startprozessfehler



Hier sind meine Einstellungen:

Pimärserver
windows 7 64 Bit
Postgresversion: 9.3
IP: 192.168.0.10
Port: 5433

Standbyserver
windows 7 64 Bit
Postgresversion: 9.3
IP: 192.168.0.20
Port: 5433

Einstellungen Primär-Server

PostgreSQL.conf
listen_addresses = ‘*’
wal_level = hot_standby
archive_mode = on
archive_command = ‘copy “%p” “\\192.168.0.10\Archive\%f”’
max_wal_senders = 2
wal_keep_segments = 32

pg_hba.conf
host replication postgres 192.168.0.20/32 trust

Neustarten des postgreSQl-Dienstes auf dem Primär-Server

Nachdem der Primärserver konfiguriert wurde, habe ich das data-Verzeichnis auf den Standby-Server kopiert.

Einstellungen Standby-Server

PostgreSQL.conf
listen_addresses = ‘*’
hot_standby = on

pg_hba.conf
host replication postgres 192.168.0.10/32 trust

recovery.conf

standby_mode = ‘on’
primary_conninfo = ‘host=192.168.0.10 port=5433 user=postgres password=postgres’
trigger_file = ‘C:\stopreplication\standby.txt’
restore_command = ‘copy “%p” \\192.168.0.10\Archive\%f %p’

Neustarten des postgreSQl-Dienstes auf dem Standby-Server

Ab hier hast Du ein Split Brain. Soll der Slave wieder Slave sein dann mache das, was Du vorher gemacht hast, noch einmal. Also Base-Backup etc.

Danke für die Antwort.

base-Backup von welcher Datenbank?

Das habe ich schon getestet.
Ich habe das komplette data-Verzeichnis vom Primärserver, auf dem der Dienst aus war, nach Standbyserver kopiert, hot_standby = on, recovery.conf erstellt und den postgreSQL-Dienst gestartet.
Nach dieser Aktion, die ich auch beim Einrichten durgeführt habe, konnte ich den postgreSQL-Dienst erfolgreich starten.

Was mache ich aber mit dem Backup, wenn der Primärserver gar nicht mehr erreichbar ist, z.B. Hardware defekt?
Wo kriege ich das Backup her?

Dann hast Du den Slave.

Ich glaube da verstehe ich was falsch oder mir fehlt einfach zusätliches Wissen um das zu verstehen :slight_smile:

Ich wollte dieses Szenario durchspielen.

1.Primärserver PR läft
2.Standbyserver ST läuft
3.Die Daten werden richtig repliziert.
4.Jetzt wird der PR abgeschaltet
5.Der ST wird durch die Triggerdatei zu PR gemacht
6.Es finden keine DB-Aktivitäten auf dem neuen PR statt
7.Nach 3 Minuten wird der alte PR angemacht
8.Der neue PR wird durch Umbenennen der recovery.done in recovery.conf wieder zu ST gemacht und neugestartet
9.Jetzt kommt der Fehler

habe ich was bei Einstellungen vergessen oder sind meine Schritte falsch?
In diesem Fall brauche ich doch kein backup, weil die Datenbanken auf beiden Server gleich geblieben sind oder?
Backup brauche ich nur dann, wenn ich eine neu Datenbank aufsetzen will oder PR und ST unterschielich sind.

Ab Punkt 5 ist der ST kein Hot Standby mehr, sondern selber Master. Du bekommst ihn nicht mehr als Standby zurück. Du kannst PR ausschalten und auf dem ST lesend zugreifen, ohne Trigger-File. Wenn Du dann den PR wieder einschaltest, läuft die Replikation wieder. Aber sobald du das Triggerfile da hinwirfst ist Schluß.

Echt,
das wusste ich nicht, dass ich den nicht mehr als ST machen kann.
Weist du auch wieso oder hast du für mich ein Quellen/Links, wo das beschrieben wird und was genau passiert nachdem die Trigger-Datei abgeholt wurde???

Vielen Dank für die schnelle Antwort

Nun, die Information, daß er nun Master ist und auch schreiben KANN steht natürlich auch im Log irgendwo. Das ist halt einfach konsistent. Es kann ja auch ‘nur’ das Kabel zwischen master und Slave raus sein, aber beide noch aktive Connections haben. Durch das werfen des Triggerfiles sagst du, daß er ab nun Master ist - da kommst nicht mehr zurück.

Das Handbuch ist immer ein guter Startpunkt:

(Hervorhebung durch mich)

Vielen Dank an alle