Per soddisfare questo requisito, dovremmo creare una sorta di filtri come TRIGGERs/RULE sul nodo slave in modo che eviti di inoltrare le istruzioni DELETE e UPDATE. Dal momento che abbiamo a che fare con Slony-I, non ha un tale meccanismo integrato per filtrare i DML mentre li riproduce sul nodo slave sebbene abbia raccolto tutti gli eventi dal nodo Master. (AFAIK Mysql, Oracle, SQL Server supportano i filtri ).
Per ottenere questo diritto, il modo tradizionale Slony-I mantiene l'unicità delle righe su tutti i nodi con il suo concetto fondamentale di tabelle che devono avere chiavi primarie. In tale progetto di architettura, è difficile escludere le istruzioni DELETE/UPDATE, prendi un esempio della colonna della chiave primaria "orderid" della tabella "orders" ha una prima istruzione INSERT con valore 100 ed è stata replicata come prima forma sul nodo slave filtrato. Successivamente un'istruzione DELETE eseguita per "orderid=100" e riga eliminata, ora se qualsiasi istruzione INSERT o UPDATE tenta di utilizzare "orderid=100", il nodo Slave colpisce con una violazione della chiave duplicata e interrompe semplicemente la replica.
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
Pertanto, la norma di attuazione che non costituisce ancora un problema dovrebbe essere estremamente cauta quando è in vigore. In realtà, tuttavia, l'applicazione di questi filtri sul nodo slave Slony-I è molto fragile, in particolare l'applicazione/sviluppatore dovrebbe sempre tenerlo a mente qualsiasi voce duplicata di riga da INSERT OR UPDATE potrebbe interrompere la replica.
Poiché le regole DML non sono possibili da sole con Slony-I, possiamo utilizzare PostgreSQL CREATE RULE…ON DELETE/ON UPDATE DO INVECE NULLA e applicare quella RULE sulla tabella tramite ALTER TABLE…ENABLE REPLICA RULE per annullare l'istruzione DELETE/UPDATE. L'utilizzo di questa opzione richiede molta disciplina, quindi puoi assicurarti che la tua candidatura e i membri del personale seguano davvero queste regole.
Per continuare con i passaggi, dovresti avere una configurazione slanciata, nella remota possibilità che tu debba configurare puoi fare riferimento al mio post precedente qui.
Passi su Slave Node (Master DB:postgres, Slave DB:demo, Port:5432):
1. Ferma i demoni slon
2. Crea SU CANCELLAZIONE e SU AGGIORNAMENTO NON FARE INVECE NIENTE regola
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. Applicare la REGOLA sulla tabella
demo=# ALTER TABLE reptest ENABLE REPLICA RULE void_delete;
ALTER TABLE
demo=# ALTER TABLE reptest ENABLE REPLICA RULE void_update ;
ALTER TABLE
4. Avvia i demoni Slon
Ora puoi notare di seguito che UPDATE/DELETE non ha alcun impatto sul nodo slave:
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)
Se l'istruzione INSERT viene eseguita con il valore 1, interromperà la replica. Si noti...!!
Ricorda, ci sono altri modi per soddisfare completamente questa richiesta come dblinks, Trigger come PRIMA DELETE...restituisce il valore NULL dalla funzione, ma credo che il modo più efficiente sarebbe usare RULE/ENABLE REPLICA RULE quando lavori con la replica Slony.
Ormai potresti aver letto molti blog sulla nuova funzionalità degli slot di replica della decodifica logica in PostgreSQL 9.4, spero che in futuro possa includere il concetto di filtro DML su Slave.
Grazie per la visita.
