Hvordan replikeres kun INSERTs ikke SLETTER/OPDATERINGER på Slony Slave Node?

For at opfylde dette krav bør vi komme med en slags filtre som TRIGGER'er/REGLER på Slave Node, så det undgår at videresende DELETE- og UPDATE-sætninger. Da vi har at gøre med Slony-I, har den ikke en sådan indbygget mekanisme til at filtrere DML'er, mens den afspiller dem på slaveknudepunktet, selvom den har samlet alle hændelser fra Master-knuden.(AFAIK Mysql,Oracle,SQL Server understøtter filtre ).

For at få denne lige, bevarer traditionelle Slony-I-måde unikke rækker på tværs af alle noder med dets kernekoncept med tabeller, der skal have primære nøgler. I et sådant arkitekturdesign er det svært at udelukke DELETE/UPDATE-sætninger, tag et eksempel på, at primærnøglekolonnen "orderid" af "ordrer"-tabellen har en første INSERT-sætning med værdien 100, og den er blevet replikeret som første form på filtreret slavenode. Senere udføres en DELETE-sætning for "orderid=100" og slettet række, hvis nu en INSERT- eller UPDATE-sætning forsøger at bruge "orderid=100", så rammer Slave-noden med duplikatnøgleovertrædelse, og den bryder simpelthen 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

Derfor er implementering af regler ikke et problem, men man bør være yderst forsigtig, når den er på plads. I virkeligheden er det dog meget skrøbeligt at anvende disse filtre på Slony-I-slaveknude, især applikationer/udviklere bør altid have dette for øje, hvis duplikatindtastning af række ved INSERT ELLER OPDATERING kan bryde replikationen.

Da DML-regler ikke er mulige alene med Slony-I, kan vi gøre brug af PostgreSQL CREATE RULE...ON DELETE/ON UPDATE GØR I STEDET INTET og anvende denne REGEL på tabellen ved at ALTER TABLE...ENABLE REPLICA RULE for at annullere DELETE/UPDATE-sætningen. Det kræver en masse disciplin at bruge denne mulighed, så du kan sikre dig, at din ansøgning og dine medarbejdere virkelig følger disse regler.

For at fortsætte med trin, bør du have sløj opsætning, hvis du har brug for at opsætte, kan du henvise til mit tidligere indlæg her.

Trin på slaveknude (Master DB:postgres, Slave DB:demo, Port:5432):

1. Stop slon-dæmoner
2. Opret PÅ SLET og VED OPDATERING GØR I STEDET INTET reglen

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. Anvend 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. Start Slon-dæmoner

Nu kan du bemærke nedenfor, at UPDATE/DELETE ikke har nogen indflydelse på Slave Node:

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)

Hvis INSERT-sætningen udføres med værdi 1, vil den bryde replikationen. Vær opmærksom på...!!

Husk, at der er andre måder at udfylde denne anmodning på, som f.eks. dblinks, triggere som FØR DELETE ... returnerer NULL-værdien fra funktionen, men jeg tror, ​​at den mest effektive måde ville være at bruge REGEL/AKTIVER REPLICA-REGEL, når du arbejder med Slony-replikering.

På nuværende tidspunkt har du måske læst mange blogs om logisk afkodning af replikeringsslots nye funktion i PostgreSQL 9.4, håber i fremtiden, at det kan omfatte konceptet med filter DML'er på slave.

Tak fordi du besøgte.