Um diese Anforderung zu erfüllen, sollten wir uns eine Art von Filtern wie TRIGGERs/RULEs auf dem Slave-Knoten einfallen lassen, damit er die Weiterleitung von DELETE- und UPDATE-Anweisungen vermeidet. Da wir es mit Slony-I zu tun haben, hat es keinen solchen eingebauten Mechanismus, um DMLs zu filtern, während es auf dem Slave-Knoten wiedergegeben wird, obwohl es alle Ereignisse vom Master-Knoten gesammelt hat. (AFAIK Mysql, Oracle, SQL Server unterstützen Filter ).
Um dies klarzustellen, behält der traditionelle Slony-I-Weg die Eindeutigkeit der Zeilen über alle Knoten bei, wobei sein Kernkonzept von Tabellen Primärschlüssel haben muss. In einem solchen Architekturdesign ist es schwierig, DELETE/UPDATE-Anweisungen auszuschließen. Nehmen Sie ein Beispiel, dass die Primärschlüsselspalte „orderid“ der Tabelle „orders“ eine erste INSERT-Anweisung mit dem Wert 100 hat und als erste Form auf dem gefilterten Slave-Knoten repliziert wurde. Später wird eine DELETE-Anweisung für „orderid=100“ und eine gelöschte Zeile ausgeführt. Wenn jetzt eine INSERT- oder UPDATE-Anweisung versucht, die „orderid=100“ zu verwenden, trifft der Slave-Knoten mit einer Verletzung des doppelten Schlüssels und es wird einfach die Replikation unterbrochen.
ERROR: duplicate key value violates unique constraint "reptest_pkey"
DETAIL: Key (id)=(2) already exists.
CONTEXT: SQL statement "INSERT INTO "public"."reptest" ("id", "name") VALUES ($1, $2);"
.....
or
....
CONTEXT: SQL statement "UPDATE ONLY "public"."reptest" SET "id" = $1 WHERE "id" = $2;"
2014-11-17 23:18:53 PST ERROR remoteWorkerThread_1: SYNC aborted
Daher ist die Durchführungsvorschrift noch kein Thema, man sollte äußerst vorsichtig sein, wenn sie in Kraft ist. In Wirklichkeit ist die Anwendung dieser Filter auf Slony-I-Slave-Knoten jedoch sehr anfällig, insbesondere sollten Anwendungen/Entwickler dies immer im Hinterkopf behalten, da jeder doppelte Eintrag einer Zeile durch INSERT OR UPDATE die Replikation unterbrechen könnte.
Da DML-Regeln allein mit Slony-I nicht möglich sind, können wir PostgreSQL CREATE RULE…ON DELETE/ON UPDATE DO INSTEAD NOTHING verwenden und diese REGEL auf die Tabelle anwenden, indem wir ALTER TABLE…ENABLE REPLICA RULE verwenden, um die DELETE/UPDATE-Anweisung aufzuheben. Die Verwendung dieser Option erfordert viel Disziplin, sodass Sie sicherstellen können, dass Ihre Anwendung und Ihre Mitarbeiter diese Regeln wirklich befolgen.
Um mit den Schritten fortzufahren, sollten Sie eine schlampige Einrichtung haben. Falls Sie eine Einrichtung vornehmen müssen, können Sie auf meinen früheren Beitrag hier verweisen.
Schritte auf Slave-Knoten (Master-DB:postgres, Slave-DB:Demo, Port:5432):
1. Slon-Daemons stoppen
2. Erstellen Sie die Regeln ON DELETE und ON UPDATE DO INSTEAD NOTHING
demo=# CREATE RULE void_delete AS ON DELETE TO reptest DO INSTEAD NOTHING;
CREATE RULE
demo=# CREATE RULE void_update AS ON UPDATE TO reptest DO INSTEAD NOTHING;
CREATE RULE
3. REGEL auf Tabelle anwenden
demo=# ALTER TABLE reptest ENABLE REPLICA RULE void_delete;
ALTER TABLE
demo=# ALTER TABLE reptest ENABLE REPLICA RULE void_update ;
ALTER TABLE
4. Slon-Daemons starten
Nun können Sie unten feststellen, dass UPDATE/DELETE keine Auswirkung auf den Slave-Knoten hat:
postgres=# delete from reptest where id =2;
DELETE 1
postgres=# update reptest set id=2 where id=1;
UPDATE 1
--On Master
postgres=# select * from reptest ;
id | name
----+------------
2 | A
(1 row)
--On Slave
demo=# select * from reptest ;
id | name
----+------------
1 | A
2 | C
(2 rows)
Wenn die INSERT-Anweisung mit dem Wert 1 ausgeführt wird, wird die Replikation unterbrochen. Achtung…!!
Denken Sie daran, dass es andere Möglichkeiten gibt, diese Anforderung vollständig zu erfüllen, wie z.
Inzwischen haben Sie vielleicht viele Blogs über die neue Funktion von Logical Decoding Replication Slots in PostgreSQL 9.4 gelesen und hoffen, dass sie in Zukunft das Konzept von Filter-DMLs auf Slave beinhalten wird.
Vielen Dank für Ihren Besuch.
