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