Information ausblenden
Willkommen im Forum für alle Datenbanken! Registriere Dich kostenlos und diskutiere über DBs wie Mysql, MariaDB, Oracle, Sql-Server, Postgres, Access uvm

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

Dieses Thema im Forum "PostgreSQL" wurde erstellt von long_forum, 28 Mai 2020.

  1. long_forum

    long_forum Benutzer

  2. castorp

    castorp Datenbank-Guru

    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
     
    Walter und akretschmer gefällt das.
  3. akretschmer

    akretschmer Datenbank-Guru

    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.
     
  4. long_forum

    long_forum Benutzer


    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?
     
  5. akretschmer

    akretschmer Datenbank-Guru

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

    castorp Datenbank-Guru

    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.
     
  7. long_forum

    long_forum Benutzer

    Danke für die Hilfe.

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

    akretschmer Datenbank-Guru

    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 :-(
     
Die Seite wird geladen...

Diese Seite empfehlen

  1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden