Re: [gelöst] Probleme Replikation aufzusetzen

Am 31.01.2018 um 16:21 schrieb Thiemo Kellner:
> Die Dateien des Base-Backup habe ich einfach ins Datenverzeichnis des
> Standbys kopiert. Ob dies nur im Falle frisch initialisierter
> Datenbanken funktioniert oder ob dies das reguläre Vorgehen ist, ist
> mir nicht klar geworden.

Also, um das noch mal zu erklären:

pg_basebackup kann einen laufenden Server sichern. Auf diesem kann
durchauch richtig viel Traffic sein. Und diese DB kann auch groß sein.
Stelle Dir 10TB vor. Die spannende Frage ist: ist denn so ein basebackup
überhaupt konsistent? Nein, ist es nicht, denn die Datenbank arbeitet
und schreibt fleißig in die Datendateien - während diese kopiert werden.

Daher besteht so ein physisches Backup immer aus 2 Teilen: die Kopie des
Datenordners UND den während des kopierens angefallenen
Transaktionslogs. Wenn der Clone dann hochfährt, muß er irgendwie an die
Transaktionsdateien kommen. Dafür gibt es mehrere Möglichkeiten:

* pg_basebackup kann die automatisch mit streamen. Das ist sogar der
Default (in aktuellen Versionen)
* pg_basebackup kann die nach dem Basebackup holen. Riskant, denn der
Master überschreibt diese Dateien nach 2 Checkpoints (ab PG11 evtl.
schon nach 1 Checkpoint)
* man hantiert mit Replication Slots
* man hantiert mit archive_command / restore_command
* man set wal_keep_segments hinreichend groß (wie groß? Gute Frage,
schätzen sie mal ...)
* man nutzt Barman (Werbung muß sein!)

Versuche, den ganzen Mechanismus zu verstehen, also was diese komischen
WAL's machen, zusammenspiel Shared Buffers, Checkpoints, Transaction Log
etc. Es ist wichtig, das zu verstehen. Das ist Grundlage der Robustheit
von PostgreSQL (es ist crash-safe!), es ist Grundlage der streaming
replication (und auch der logischen Replikation ab PG 10, BDR & Co), es
ist Grundlage für Point-In-Time-Recovery.

Andreas

--
2ndQuadrant - The PostgreSQL Support Company.
www.2ndQuadrant.com