"Streaming-Replikation" bezieht sich auf das kontinuierliche Senden von WAL-Datensätzen über eine TCP / IP-Verbindung zwischen dem Master und dem Replikat unter Verwendung des Walsender-Protokolls über replicationVerbindungen. Der Master liest seine eigene WAL von pg_xlogund sendet sie bei Bedarf an die Replik. Es ist mit einer primary_conninfoDirektive in recovery.confund pg_hba.confEinträgen auf dem Master konfiguriert , um replicationVerbindungen zuzulassen . Sie müssen auch wal_keep_segmentsund einige andere Optionen in der Dokumentation behandelt.
"Protokollversand" bezieht sich auf das regelmäßige Senden von WAL-Datensätzen als ganze WAL-Archive über ein Dateiübertragungsprotokoll an einen Archivspeicherort, von dem das Replikat sie dann abrufen kann. Es ist mit einer restore_commandDirektive in recovery.confund einer archive_commandim Master konfiguriert . PostgreSQL ist es egal, wo sich die Dateien befinden oder wie sie übertragen werden, nur dass archive_commandsie dort abgelegt werden und restore_commanddas erforderliche Archiv abgerufen wird. Dies ermöglicht den Aufbau von Systemen wie PgBarman und WAL-E.
Die Streaming-Replikation weist nicht so viele Verzögerungen auf, da Datensätze gesendet und generiert werden. Es ist jedoch erforderlich, dass sowohl der Master als auch das Replikat online sind und direkt kommunizieren können. Außerdem muss das Replikat gut genug mithalten, damit der Master noch Kopien der WAL auf der Festplatte hat, die das Replikat benötigt, und im Allgemeinen müssen Sie zusätzlichen pg_xlogSpeicherplatz für die Aufbewahrung zusätzlicher WAL für das Replikat aufwenden.
Die Protokollversandreplikation weist eine größere Verzögerung auf, da das Replikat WAL erst sieht, wenn ein ganzes Archiv gesendet wurde. Es kann jedoch auch dann funktionieren, wenn der Master und das Replikat nicht direkt über TCP / IP unter Verwendung eines gemeinsam genutzten Speicherorts kommunizieren können. Es funktioniert auch dann weiter, wenn das Replikat eine Weile nicht pg_xlogverfügbar ist , da der Master die WAL erst nach der Archivierung verworfen hat. Die WAL befindet sich also weiterhin im Archiv und kann von der Replik verwendet werden, obwohl der Master sie nicht senden kann durch Streaming mehr. Beachten Sie, dass dies archive_commandniemals aufgibt und sich daher pg_xlogfüllen kann, wenn die Archivierung fehlschlägt. Aus diesem Grund ist es besser, an einem zuverlässigen Speicherort zu archivieren und dann den Replikatserver von diesem Speicherort abrufen zu lassen.
Im Allgemeinen kombinieren Sie die beiden tatsächlich, dh verwenden Sie beide. In diesem Fall wird die Streaming-Replikation verwendet, wenn alles in Ordnung ist. Wenn das Replikat zu weit zurückliegt und der Master die erforderlichen Xlogs verworfen hat, ein Konnektivitätsproblem usw. auftritt, wechselt das Replikat zum Lesen der archivierten WAL, bis es eingeholt wird. Es wird regelmäßig erneut versucht, zum Streaming zurückzukehren, bis dies erfolgreich ist.
Wenn Sie nur einen verwenden möchten, verwenden Sie den Protokollversand, da das Streaming der Replikation ohne Fallback für den Protokollversand (bis PostgreSQL 9.4) möglicherweise zu Replikationsverzögerungen führt, die zu Fehlern führen, die die Neuerstellung eines Replikats erzwingen.
PostgreSQL 9.4 ändert dies ein wenig, da die Streaming-Replikation jetzt "Replikations-Slots" verwenden kann. Auf diese Weise kann der Master verfolgen, wie viel WAL ein Replikat benötigt, und es vermeiden, es wegzuwerfen, bis das Replikat es wiedergegeben hat. wal_keep_segmentsWenn Sie einen Replikationssteckplatz verwenden (nicht die Standardeinstellung), ist dies nicht mehr erforderlich .
Siehe meinen Artikel zum Streamen von Replikationssteckplätzen in PostgreSQL 9.4 .
In 9.4 werden auch die Grundlagen für das Streaming der logischen Replikation vorgestellt. Dies ist ein weiterer Mechanismus, der für die Verwendung durch logische Replikationssysteme wie Londiste, Slony-I und die neue bidirektionale asynchrone Multi-Master-Replikationsfunktion entwickelt wurde .