it-swarm.com.de

PostgreSQL 9.1 Hot Backup-Fehler: Das Datenbanksystem wird gestartet

Ich habe eine Weile an einem Hot-Backup für Postgres 9.1 gearbeitet und bin auf ein konsistentes Problem gestoßen. Nach dem Neustart von Postgres auf dem Slave-Server werden die Protokolldatei pgstartup und die tägliche Protokolldatei im Verzeichnis pg_log fehlerfrei gelesen. Wenn ich jedoch versuche, mit dem Befehl psql in die Datenbank einzutreten, wird folgende Fehlermeldung angezeigt:

 FATAL: Das Datenbanksystem wird gestartet. 

Die Datei recovery.conf wird auch nicht in recovery.done umgewandelt. Ich habe diesen Fehler eingehend untersucht und finde immer die gleiche Antwort: Die Datenbank wurde nicht sauber heruntergefahren, bevor ich versuchte, Postgres neu zu starten. Die einzige Möglichkeit, Postgres neu zu starten, ist das service postgresql-9.1 restart oder /etc/init.d/postgresql-9.1 restart Befehle. Nachdem ich diesen Fehler erhalten habe, beende ich alle Prozesse und versuche erneut, die Datenbank neu zu starten, und erhalte immer noch den gleichen Fehler. Ich weiß nicht, wohin ich von hier aus gehen soll und wie ich dieses Problem beheben kann. Nachfolgend finden Sie den genauen Vorgang, den ich ausgeführt habe, um das Hot-Backup abzuschließen.

Master Server Konfigurationen :

pg_hba.conf, fügte die Zeile hinzu:

 Host-Replikation postgres IPAddressOfSlaveServer-Vertrauen 

postgresql.conf:

 wal_level = hot_standby 
 Max_wal_senders = 5 
 listen_address = '*' 
 port = 5432 
 Max_wal_senders = 5 
 wal_keep_segments = 32 

Slave-Server-Konfigurationen :

postgresql.conf:

 hot_standby = on 

recovery.conf:

 standby_mode = on 
 primary_conninfo = Host = IPAddressOfMasterServer 
 port = 5432 
 user = postgres 
 restore_command = 'cp/var/lib/pgsql/9.1/data/pg_xlog /% f "% p" '

Nach der Konfiguration beider Server

Ich wechsle zum Benutzer postgres auf dem Master-Server und führe die folgenden Befehle aus:

 Psql -c "Wählen Sie pg_start_backup ('label', true);"; 
 Rsync -a -v -e ssh /var/lib/pgsql/9.1/data Slave:/var/lib /pgsql/9.1/data\
 - postmaster.pid ausschließen 
 pgsql -c "select pg_stop_backup ();"; 

Nach dem Synchronisieren der Datenbank mit dem Slave-Server

Ich starte den Slave-Server neu und der Start schlägt nicht fehl. Das pgstartup.log lautet:

Erfolg. Sie können den Datenbankserver jetzt folgendermaßen starten: 
 
 /USr/pgsql-9.1/bin/postgres -D /var/lib/pgsql/9.1/data[.____.‹oder
 /usr/pgsql/9.1/bin/pg_ctl -D /var/lib/pgsql/9.1/data -l Protokolldatei starten 

die aktuelle Tagesprotokolldatei, postgresql-Thu.log, lautet:

 Protokoll: Herunterfahren 
 Protokoll: Datenbanksystem wird heruntergefahren 
 Protokoll: Das Datenbanksystem wurde bei der Wiederherstellung am 10.4.2012 
 Protokoll heruntergefahren Modus 
 Protokoll: Wiederhergestellte Protokolldatei "logFileName" aus dem Archiv 
 Protokoll: Konsistenter Wiederherstellungsstatus bei 0/BF0000B0 
 Protokoll: Wiederholung beginnt bei 0/BF000020 
 Protokoll : Wiederhergestellte Protokolldatei "logFileName" aus dem Archiv 
 Protokoll: Unerwarteter Pageaddr 0/85000000 in Protokolldatei 0, Segment 192, Offset 0 
 Protokoll: Unerwarteter Pageaddr 0/85000000 in Protokolldatei 0, Segment 192 , Offset 0 
 Protokoll: Streaming-Replikation erfolgreich mit primärem 
 verbunden.

Ich habe unerwartete pageaddr recherchiert und aus den Postgres-Archiven habe ich verstanden, dass dies ganz normal ist und eine der erwarteten Möglichkeiten ist, das Ende der WAL zu erkennen.

Jeder Rat wäre sehr dankbar.

16
Jen

Die Meldung "Das Datenbanksystem wird gestartet." zeigt keinen Fehler an. Der Grund, warum es sich auf der Ebene von FATAL befindet, ist, dass es immer in das Protokoll gelangt, unabhängig von der Einstellung von log_min_messages:

http://www.postgresql.org/docs/9.1/interactive/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN

Haben Sie nach dem rsync wirklich ausgeführt, was Sie zeigen?:

 Pgsql -c "wähle pg_stop_backup ();"; 

Da es meines Wissens keine ausführbare Datei pgsql gibt, würde die Sicherung unvollständig bleiben und der Slave würde den Wiederherstellungsmodus niemals verlassen. Andererseits haben Sie vielleicht wirklich psql ausgeführt, weil ich sonst nicht sehe, wie der Slave solche Erfolgsmeldungen protokolliert hätte:

 Protokoll: Konsistenter Wiederherstellungsstatus bei 0/BF0000B0 erreicht. 

und:

 Protokoll: Streaming-Replikation erfolgreich mit primärem 
 Verbunden.

Haben Sie zu diesem Zeitpunkt versucht, eine Verbindung zum Slave herzustellen? Was ist passiert?

Die von Ihnen erwähnte Meldung "Erfolgreich. Sie können jetzt beginnen ..." wird von initdb generiert, die nicht als Teil der Einrichtung eines Slaves ausgeführt werden sollte. Ich denke, Sie könnten über etwas verwirrt sein. Ich bin auch besorgt über diese scheinbar widersprüchlichen Aussagen:

Die einzige Möglichkeit, Postgres neu zu starten, besteht in den Befehlen postgresql-9.1 restart oder /etc/init.d/postgresql-9.1 restart. Nachdem ich diesen Fehler erhalten habe, beende ich alle Prozesse und versuche erneut, die Datenbank neu zu starten ...

Haben Sie versucht, den Dienst über das Dienstskript zu stoppen? Was ist passiert? Es kann hilfreich sein, die Protokolle zu verstehen, wenn Sie Zeilen mit weiteren Informationen voranstellen. Wir gebrauchen:

log_line_prefix = '[%m] %p %q<%u %d %r> '

Das recovery.conf Skript sieht seltsam aus. Kopieren Sie aus dem Verzeichnis pg_xlog des Masters, dem aktiven Verzeichnis pg_xlog des Slaves oder einem Archivverzeichnis?

11
kgrittn

Ich hatte auch einige Probleme damit, außer dass ich auf 9.3 war, nicht auf 9.1. Wie auch immer, das Update erwies sich als ziemlich trivial:

Die postgresql.conf - Datei wurde vom Master auf den Slave kopiert, und ich habe sie auf dem Slave unverändert gelassen. Ich dachte, Sie müssten nur eine recovery.conf - Datei hinzufügen, und alles würde funktionieren (gut, aber ich konnte mich nicht beim replizierten Slave-Server anmelden, aber es wurde repliziert).

Ich habe die postgresql.conf - Datei des Slaves bearbeitet und:

  • kommentierte den archive_mode=on
  • auskommentierter archive Befehl; und
  • auskommentiert hot_standby=on

Das hat es geschafft: Ich konnte die Datenbank zu einem schreibgeschützten Server machen, der bereit ist, schreibgeschützte Abfragen zu akzeptieren.

Es gibt ein Skript namens pg_basebackup, Das das Verzeichnis bootstrap für den Slave) erstellt. Dies ist das Datenverzeichnis mit der Datenbank darin. Sie müssen den postgresql.conf Datei, bevor sie wie beschrieben als Slave verwendet werden kann, was für ein Post-Skript pg_basebackup ziemlich einfach ist.

8
Greg

Interessanterweise habe ich das anders gelöst als Paulus.

Ich fügte hinzu:

hot_standby = on

oder vielmehr geändert #hot_standby = off zu dem darüber. (Dies war mit 9,5)

7
user41734

Ich habe dies in Protokollen:

MSK FATAL:  the database system is starting up

Um den unendlichen Start des Servers zu beheben, gehen Sie folgendermaßen vor: Beenden Sie den Dienst (falls vorhanden), beenden Sie den Prozess 'postgres' (normalerweise vorhanden). Führen Sie dies in der Konsole aus:

pg_resetxlog.exe -D ../Data -f

Diese Verwendung wird angezeigt, weil das xLog-Verzeichnis Daten enthält, die vor dem Herunterfahren des Dienstes nicht geschrieben wurden. Und dann versucht er beim Start des Dienstes, diese Daten zu reparieren. Manchmal friert es den Start ein und endet nie. Befehl beim Bereinigen bereinigt diese nicht fixierten Daten, die den Dienst anwenden, um nur mit festen Daten zu beginnen. Möglicherweise gehen einige Teile nicht fixierter Daten verloren, aber der Datenbankserver läuft normal und kann von Apps aufgerufen werden.

1