Replizieren einiger Tabellen von einer Postgres-Datenbank in eine andere

Ich habe die folgende Situation: Ich habe drei Computer, auf denen Postgresql-Datenbanken ausgeführt werden. Ein Computer enthält Client-Kontoinformationen (rufen Sie diesen Computer C auf), die anderen beiden Computer enthalten Client-Protokollierungsinformationen (nennen Sie diese L1 und L2). Der Grund für die Aufteilung besteht darin, das Laden auf mehrere Computer zu trennen (einige Clients senden Protokollierungsinformationen an L1, einige an L2 ... und möglicherweise einige Zeit an L3, L4, ...).

Beim Abrufen von Protokollierungsinformationen möchte ich im Prinzip in der Lage sein, zwischen Protokollierungstabellen in Ln und den Clientkontotabellen in C zu verbinden. In Wirklichkeit kann ich solche Verbindungen nicht erstellen (und selbst wenn ich könnte, würde ich es wollen um das Laden zu vermeiden C).

Mein Gedanke ist, die Tabellen auf C auf jedes von L1, L2, ... zu replizieren, damit ich die Verknüpfungen durchführen kann. In Bezug auf die Tabellen von C ist C Master und L1, L2, ... sind Slaves. Aber für die anderen Tabellen auf L1, L2, ... sind diese Maschinen Meister. Es ist nicht genau Master-Master-Replikation, und es ist nicht genau Master-Slave.

Kann die Postgres-Replikation (ich verwende 9.1) dazu überredet werden, oder wenn nicht, gibt es andere Pakete, die diese Aufgabe übernehmen würden? In letzter Instanz kann ich Code schreiben, um die Tabellen regelmäßig zu synchronisieren (ich kann Verzögerungen tolerieren), aber es wäre schön, dies nicht zu tun!

Danke im Voraus.

Unter PostgreSQL 9.3 können Sie postgres_fdwdie Fremdtabelle auf dem anderen Computer transparent abfragen.

Bei älteren Versionen dblinkkann dies eine Option sein, wie von Andrew erwähnt.

Eine andere Möglichkeit besteht darin, ein Tool wie Londiste oder Slony-I zu verwenden, um die gewünschten Tabellen zu replizieren. Ich empfehle Londiste dafür, es wird viel einfacher. Es erstellt Trigger in der Tabelle, um das Einfügen / Aktualisieren / Löschen zu erkennen, und repliziert diese mithilfe seines eigenen Clients / Servers und eines Warteschlangensystems in die andere Datenbank, wo es das entsprechende Einfügen / Aktualisieren / Löschen ausführt. Ich benutze es in der Produktion auf mehreren Kundenstandorten und es funktioniert sehr gut.

Eine zukünftige Option (hoffentlich in PostgreSQL 9.5) ist die logische Replikation des Protokoll-Streamings, die Extraktion logischer Änderungssätze und die bidirektionale Replikation, mit der einzelne Datenbanken oder Tabellen auf SQL-Ebene repliziert werden können. Ein Teil der Arbeit hierfür war PostgreSQL 9.4 gewidmet, aber nicht genug, um es für das, was Sie tun möchten, nützlich zu machen.

Sie sollten dblinks und materialisierte Ansichten verwenden, um dies zu erreichen. Beide Funktionen sind in die neuesten Versionen von Postgres integriert:

http://www.postgresql.org/docs/9.3/static/rules-materializedviews.html

http://www.postgresql.org/docs/9.3/static/dblink.html

Im Wesentlichen erstellen Sie eine Mview für jede Datenbank L1, L2 ... mit Daten, die aus den Tabellen in C extrahiert wurden, und verwenden dann die Mview-Aktualisierung, um die Mviews regelmäßig so häufig wie erforderlich zu aktualisieren. Die Daten werden lokal gespeichert, sodass der Zugriff sehr schnell erfolgt. Dies ist nur geeignet, wenn die Daten relativ statisch sind und Sie nichts dagegen haben, dass die lokalen Datenbanken gelegentlich leicht veraltete Informationen enthalten. Sie sollten die Aktualisierungsfrequenzen festlegen, um dies angemessen zu verwalten. Wenn dies nicht akzeptabel ist, sollten Sie einfach eine Datenbankverbindung verwenden und mit der daraus resultierenden Langsamkeit umgehen.

Wenn Sie zusätzliche Funktionen benötigen, bietet das Snapshots-Projekt erweiterte Funktionen wie schnelle Aktualisierungen und Snapshot-Protokolle:

http://pgfoundry.org/projects/snapshot/

Mit dieser Option können Sie bei den Aktualisierungen nur Zeilen aktualisieren, die aktualisiert werden müssen. Dadurch können sie für große, unelastische Datasets extrem schnell ausgeführt werden, wodurch Störungen Ihrer App minimiert werden. Standardmäßig werden Mviews in Postgres vollständig gelöscht und neu erstellt, was aus offensichtlichen Gründen für die Leistung sehr schlecht sein kann.