Replikation ohne bestehende DB auf Slave zu überschreiben möglich?

[long_forum]

Ist es möglich eine Master-Slave-Replikation einzurichten, ohne dass die bestehende schon vorhandene Datenbank auf dem Slave überschrieben wird?

Master-Slave-Betrieb funktioniert so weit schon, aber leider halt so, dass die Datennbank überschrieben wird!

https://www.howtoforge.de/anleitung...ikation-fr-postgresql-96-auf-ubuntu-1604-ein/

 

[castorp]

Wenn Du Replikation über Streaming Replication bzw. WAL Archiving meinst, dann: nein, das geht nicht. Es wird ja nicht nur eine "Datenbank" sondern die gesamte Instanz (aka "cluser", "data directory") repliziert.

Wenn Du selektiv nur eine Datenbank der Instanz replizieren willst, dann geht das nur mittels logical replication.
PostgreSQL: Documentation: 12: Chapter 30. Logical Replication

 

[akretschmer]

Siehe @castorp . Der Vollständigkeit halber, es gibt auch Trigger-basierte Replikationen, z.B. Slony. Das sind aber alte Geschichten, die heute keiner mehr auf Neusystemen verwendet.

 

[long_forum]

Wenn Du selektiv nur eine Datenbank der Instanz replizieren willst, dann geht das nur mittels logical replication.
PostgreSQL: Documentation: 12: Chapter 30. Logical Replication

Habe ich mir angeschaut - aber das hilft mir leider nicht, da meine Tabellen beide gleich heißen (SystemEvents) und er mir meine bestehende Tabelle auf dem Slave dann "überschrieben" würde - gibt es da einen Trick es irgendwie anders zu transferieren bzw. gerade und ungerade Schlüssle zu verwenden, schon beim Erstellen der Tabelle?

 

[akretschmer]

Trick es irgendwie anders zu transferieren bzw. gerade und ungerade Schlüssle zu verwenden, schon beim Erstellen der Tabelle?

genau das wäre eine Lösung. Du kannst bei Sequencen den Startwert und den Offset definieren.

 

[castorp]

Habe ich mir angeschaut - aber das hilft mir leider nicht, da meine Tabellen beide gleich heißen (SystemEvents)

Das ist ja eine Vorraussetzung dafür dass man logical Replication überhaupt verwenden kann. "Überschrieben" wird dabei nur was, wenn in der Quelle ein UPDATE gemacht wird - das wird dann natürlich auch in der Zieltabelle gemacht und "überschreibt" damit etwas.

Ansonsten kann es natürlich zu Konflikten kommen wenn Daten in der Quelle eingefügt werden, die im Ziel schon existieren.

 

[long_forum]

Danke für die Hilfe.

Habe es jetzt mit Hilfe von geraden und ungeraden Schlüsseln und der logischen Replikation gelöst.

 

[akretschmer]

der Vollständigkeit halber, es gibt weitere Lösungen:

• verwenden von UUID's. Die sollten nicht so schnell kollidieren... BDR hat KSUUD (sind sortierbar nach timestamp)
• Zuweisen von Blöcken. Also, Node 1 bekommt den Bereich von 1 bis 1 Milliarde, Node 2 von 1 Milliarde bis 2 Milliarden etc.
• wie eben, aber diese Blöcke werden bei Bedarf dann auch dynamisch neu zugewiesen, in kleinern Schritten. Nutzt unser BDR. Je nach Datentyp (smallint, int, bigint) werden dann 1.000, 1.000.000 oder 1.000.000.000 große Blöcke zugewiesen. Die Nodes verwenden dann den Block, und wenn sie zuende gehen, wird via globalem consensus ein neuer Block den Nodes zugewiesen. Das ist auch der Nachteil: der globale consensus.
• cool sind 'timeshard sequences' Diese enthalten die Node-ID, wo sie generiert wurden, einen Timestamp wann generiert und sind ansonsten unique. Jede Node kann bis zu 8192 Werte pro Millisekunde erzeugen. Gibt es aber auch nur in unserem BDR.
• zusammengesetzte Keys, die als Variante zu step/offset noch extra die Node-ID (z.B.) beinhalten

Mehr Informationen und Beispiele dazu in der BDR-Doku - die ich leider nicht frei veröffentlichen darf :-(