Wie behebe ich einen PostgreSQL 9.3-Slave, der nicht mit dem Master mithalten kann?

Question

Wir haben eine Master-Slave-Replikationskonfiguration wie folgt.

Auf dem Master:

postgresql.conf hat Replikation wie folgt konfiguriert (Kommentarzeile der Kürze halber entnommen):

max_wal_senders = 1    
wal_keep_segments = 8   

Am Nehmer:

Same postgresql.conf wie auf dem Master. recovery.conf sieht wie folgt aus:

standby_mode = 'on' 
primary_conninfo = 'host=master1 port=5432 user=replication password=replication' 
trigger_file = '/tmp/postgresql.trigger.5432' 

Wenn diese zunächst Setup war, haben wir ein paar einfache Tests durchgeführt und bestätigt die Replikation arbeitete. Wenn wir jedoch die anfängliche Datenladung durchgeführt haben, gelangten nur einige der Daten zum Slave.

Sklaves log jetzt mit Nachrichten, die wie folgt aussehen gefüllt ist:

< 2015-01-23 23:59:47.241 EST >LOG: started streaming WAL from primary at F/52000000 on timeline 1 
< 2015-01-23 23:59:47.241 EST >FATAL: could not receive data from WAL stream: ERROR: requested WAL segment 000000010000000F00000052 has already been removed 

< 2015-01-23 23:59:52.259 EST >LOG: started streaming WAL from primary at F/52000000 on timeline 1 
< 2015-01-23 23:59:52.260 EST >FATAL: could not receive data from WAL stream: ERROR: requested WAL segment 000000010000000F00000052 has already been removed 

< 2015-01-23 23:59:57.270 EST >LOG: started streaming WAL from primary at F/52000000 on timeline 1 
< 2015-01-23 23:59:57.270 EST >FATAL: could not receive data from WAL stream: ERROR: requested WAL segment 000000010000000F00000052 has already been removed 

Nach einiger Analyse und helfen auf dem #postgresql IRC-Kanal, habe ich zu dem Schluss gekommen, dass der Slave nicht mit dem mithalten kann Meister. Meine vorgeschlagene Lösung ist wie folgt.

Auf dem Master:

1. Set max_wal_senders=5
2. wal_keep_segments=4000 Set. Ja, ich weiß, es ist sehr hoch, aber ich würde gerne die Situation beobachten und sehen, was passiert. Ich habe Platz auf dem Meister.

Auf dem Slave:

1. Speicher von Konfigurationsdateien im Datenverzeichnis (das heißt pg_hba.conf pg_ident.conf postgresql.conf recovery.conf)
2. löscht aus dem Datenverzeichnis (rm -rf /var/lib/pgsql/9.3/data/*). Dies scheint von pg_basebackup erforderlich zu sein.
3. den folgenden Befehl ausführen: pg_basebackup -h master -D /var/lib/pgsql/9.3/data --username=replication --password

ich etwas fehle? Gibt es einen besseren Weg, den Slave auf den neuesten Stand zu bringen, ohne alle Daten neu laden zu müssen?

Jede Hilfe wird sehr geschätzt.

Answer 1

Die zwei wichtige Optionen für die WAL für streaming replication Umgang:

• wal_keep_segments sollte hoch genug eingestellt werden, ein Sklave zu ermöglichen, nach einer angemessenen Verzögerung (zB hohe Update-Volumen, offline zu sein Slave aufholen, etc...).

• archive_mode ermöglicht WAL-Archivierung, die zum Wiederherstellen von Dateien älter als wal_keep_segments verwendet werden kann. Die Slave-Server benötigen lediglich eine Methode zum Abrufen der WAL-Segmente. NFS ist die einfachste Methode, aber alles von scp über http bis hin zu Bändern funktioniert, solange es gescriptet werden kann.

  # on master 
  archive_mode = on 
  archive_command = 'cp %p /path_to/archive/%f' 
  
  # on slave 
  restore_command = 'cp /path_to/archive/%f "%p"' 
  

  Wenn der Slave nicht das WAL-Segment vom Master direkt ziehen kann, wird er versuchen, die restore_command zu verwenden, um es zu laden. Sie können den Slave so konfigurieren, dass Segmente automatisch mit der Einstellung archive_cleanup_command entfernt werden.

Wenn der Slave zu einer Situation kommt, wo die nächste WAL Segment es muss von fehlt sowohl der Master und das Archiv, gibt es keine Möglichkeit, um konsequent die Datenbank wiederherstellen. Die einzige vernünftige Option ist dann, den Server zu schrubben und wieder von einem frischen pg_basebackup zu starten.

Answer 2

Wie Ben Grimm in den Kommentaren vorgeschlagen hat, geht es darum, Segmente auf den maximal möglichen Wert zu setzen, damit der Slave aufholen kann.