Hur replikerar man endast INSERTs inte DELETEs/UPDATEs på Slony Slave Node?

För att uppfylla detta krav bör vi komma med något slags filter som TRIGGERS/REGLER på slavnoden så att den undviker att vidarebefordra DELETE- och UPDATE-satser. Eftersom vi har att göra med Slony-I, har den inte en sådan inbyggd mekanism för att filtrera DML:er medan du spelar upp dem på slavnoden, även om den har samlat alla händelser från Masternoden. (AFAIK Mysql, Oracle, SQL Server stöder filter ).

För att få det här raka, upprätthåller traditionella Slony-I-sättet unika rader över alla noder med dess kärnkoncept med tabeller måste ha primärnycklar. I en sådan arkitekturdesign är det svårt att utesluta DELETE/UPDATE-satser, ta ett exempel på att primärnyckelkolumnen "orderid" i tabellen "order" har en första INSERT-sats med värdet 100 och den har replikerats som första form på filtrerad slavnod. Senare kördes en DELETE-sats för "orderid=100" och raderad rad, nu om någon INSERT- eller UPDATE-sats försöker använda "orderid=100" så träffar slavnoden med duplicerad nyckelöverträdelse och det bryts enkelt replikeringen.

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

Att implementera regeln är alltså inte en fråga ännu, man bör vara extremt försiktig när den är på plats. I verkligheten är det dock väldigt ömtåligt att använda dessa filter på Slony-I-slavnoden, speciellt program/utvecklare bör alltid ha detta i åtanke, varje dubblerad radinmatning genom INFOGA ELLER UPPDATERA kan bryta replikeringen.

Eftersom DML-regler inte är möjliga ensamma med Slony-I, kan vi använda PostgreSQL CREATE RULE...ON DELETE/ON UPDATE GÖR INGENTING I STÄLLET och tillämpa den REGELn på tabellen genom ALTER TABLE...ENABLE REPLICA RULE för att ogiltigförklara DELETE/UPDATE-satsen. Att använda det här alternativet kräver mycket disciplin, så du kan säkerställa att din ansökan och personal verkligen följer dessa regler.

För att fortsätta med steg bör du ha slarviga inställningar, om du behöver konfigurera kan du hänvisa till mitt tidigare inlägg här.

Steg på slavnoden (Master DB:postgres, Slave DB:demo, Port:5432):

1. Stoppa slon-demoner
2. Skapa ON DELETE och ON UPDATE GÖR I STÄLLET INGENTING-regeln

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. Tillämpa REGEL på bordet

demo=# ALTER TABLE reptest ENABLE REPLICA RULE void_delete;
ALTER TABLE
demo=# ALTER TABLE reptest ENABLE REPLICA RULE void_update ;
ALTER TABLE

4. Starta Slon-demoner

Nu kan du märka nedan att UPDATE/DELETE inte har någon inverkan på slavnoden:

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)

Om INSERT-satsen körs med värde 1 kommer den att bryta replikeringen. Notera...!!

Kom ihåg att det finns andra sätt att fylla i denna begäran som dblinks, triggers som BEFORE DELETE...returnerar NULL-värde från funktionen, men jag tror att det mest effektiva sättet skulle vara att använda REGEL/AKTIVERA REPLIKSREGEL när du arbetar med Slony-replikering.

Vid det här laget kanske du har läst många bloggar om nya funktioner för logisk avkodning av replikeringsplatser i PostgreSQL 9.4, hoppas att det i framtiden kan inkludera konceptet med filter-DML på slav.

Tack för ditt besök.