Postgres wiederherstellen/Update mit WAL auf geklonte VM statt mit basebackup

Question

Enviroment: 800GB Postgres-Datenbank (OpenSuse)

Normale Wiederherstellung-Prozess:

• Sie pg_basebackup wiederherstellen müssen (von sagen wir: jeden Samstag)
• Sie haben WAL Dateien von letzten Samstag bis heute
• Zuerst: Wiederherstellen mit pg_basebackup
• Dann: Aktualisieren Sie die Datenbank mit WAL -Dateien, um die neuesten Daten zu haben. (Mit recovery.conf)

Meine Idee:
Warum jede Woche großen pg_basebackup tun und kopiert 800GB über das Internet zu NAS, wenn Sie jeden Tag inkrementelle Backups mit einiger Backup-Software.

• wiederherstellen kompletten Datenbank-vm (Stand gestern)
• hinzufügen WAL-Dateien (Restore) auf dem aktuellen Stand diesen vm-Klon zu bringen.
  

Jetzt habe ich getan:

• I
eine vm restauriert

• recovery.conf

  restore_command = 'cp /.../%f% p' erstellen

• rcpostgresql start

ich folgende Fehler:

2017-05-09 16:46:07.780 CEST [2938]: [1-1] user=,db=,app=,client= LOG: database system was shut down at 2017-05-09 16:45:47 CEST 
2017-05-09 16:46:07.780 CEST [2938]: [2-1] user=,db=,app=,client= LOG: starting archive recovery 
2017-05-09 16:46:08.588 CEST [2952]: [1-1] user=[unknown],db=[unknown],app=[unknown],client=[local] LOG: connection received: host=[local] 
2017-05-09 16:46:08.588 CEST [2952]: [2-1] user=postgres,db=postgres,app=[unknown],client=[local] FATAL: the database system is starting up 
2017-05-09 16:46:09.391 CEST [2938]: [3-1] user=,db=,app=,client= LOG: restored log file "000000010000070D0000008A" from archive 
2017-05-09 16:46:09.434 CEST [2938]: [4-1] user=,db=,app=,client= LOG: contrecord is requested by 70D/8A000028 
2017-05-09 16:46:09.434 CEST [2938]: [5-1] user=,db=,app=,client= LOG: invalid primary checkpoint record 
2017-05-09 16:46:09.434 CEST [2938]: [6-1] user=,db=,app=,client= LOG: invalid secondary checkpoint link in control file 
2017-05-09 16:46:09.434 CEST [2938]: [7-1] user=,db=,app=,client= PANIC: could not locate a valid checkpoint record 
2017-05-09 16:46:09.434 CEST [2936]: [4-1] user=,db=,app=,client= LOG: startup process (PID 2938) was terminated by signal 6: Aborted 
2017-05-09 16:46:09.434 CEST [2936]: [5-1] user=,db=,app=,client= LOG: aborting startup due to startup process failure 

Nach pg_resetxlog die nächste WAL-Datei wiederhergestellt wurde. und ich bekomme denselben Fehler (mit dem nächsten wal-datei-name)

Gibt es eine Möglichkeit, das funktioniert zu bekommen?

Answer 1

Nach ein paar Tagen konnte ich das funktionieren. @Vao Tsuns Hilfe bringt mich in die richtige Richtung, aber leider nicht notwendig.

Wie Sie Postgres-Datenbank mit WAL-Dateien und komplettem VM Backup wiederherstellen | Restore:

• Sicherung:
  • [Vielleicht einen neuen Postgres Kontrollpunkt erstellen. für mich war es nicht nötig aber mein letzter Checkpoint war nicht zu alt; für Checkpoints gibt es einen direkten Weg ohne pg_start_backup()]
  • eine einfache Sicherung Ihrer VM Haben die Postgres-Datenbank enthält. voll/inkrementell -> Ihre Wahl. (Ich mache das, während VM lief)
  • select pg_start_backup('some label') ist NICHT erforderlich.
    Nur normale Sicherung mit [vielleicht einem Kontrollpunkt vor]
• VM wieder her:
  • Sie NICHT Boot diese automatisch VM. Sie müssen sicherstellen, dass postgres nicht automatisch startet. Sie können dies mit einem speziellen Boot-Modus tun, wenn Sie Postgres-Binary oder Data-Verzeichnis mit Live-Linux-CD umbenennen oder ein Skript haben, das prüft, ob System wiederhergestellt wurde, damit Postgres nicht starten sollte.
  • Boot-VM
  • [Vielleicht überprüfen Sie pg_log-Datei, wenn die Deaktivierung von Postgres funktioniert.-> keine neue Protokolldatei]
• Datenbank wiederherstellen:
  • schaffen die recovery.conf innerhalb des $ PGDATA Verzeichnis:
    restore_command = 'cp /[path_to_your_wal_backups]/%f "%p"' recovery_target_timeline = 'latest'
  • Start Postgres
  • sehen pg_log, wenn die Wiederherstellung von wal files works
  • [Verbindung zur Datenbank herstellen. und die Suche nach neuen Daten als letzten Test]

Answer 2

Von Ihrem Fehler I angenommen Sie übersprungen pg_start_backup. Andernfalls Sie should have missing checkpoint:

pg_start_backup akzeptiert beliebige benutzerdefinierte Label für die Sicherung. (Normalerweise würde dies der Name sein, unter dem die Sicherungsdump-Datei gespeichert wird.) Wenn sie im exklusiven Modus verwendet wird, schreibt die Funktion eine Sicherungslabel-Datei (backup_label) und, falls es Verknüpfungen im Verzeichnis pg_tblspc/gibt. Eine Tabellenbereichszuordnungsdatei (tablespace_map) in das Datenverzeichnis des Datenbankclusters führt einen Prüfpunkt aus, und anschließend gibt den Speicherort des Transaktionsprotokolls der Sicherung als Text zurück.

• Backup:

Nach der Logik sollte die Reihenfolge diese sein

1. am Tag vor - kurz vor dem VM kopieren, select pg_start_backup('some label') laufen (stellen Sie sicher, dass es Ort zurück - Es kann lange dauern, einen Sicherungspunkt zu erstellen oder eine schnelle Erstellung beim IO-Spike-Preis zu erzwingen.
2. VM-Sicherung
3. select pg_stop_backup()

wiederherstellen:

1. ich vm
2. erstellen recovery.conf mit restore_command = 'cp /.../%f %p'
3. restauriert rcpostgresql
4. Menschen wissen lassen, beginnen, wenn es

gearbeitet

Auch könnte yo wollen über die pg_control, chechpoints lesen und erholen Sequenz here.