Para cumplir con este requisito, debemos idear algún tipo de filtros como TRIGGERs/RULEs en Slave Node para que evite transmitir declaraciones DELETE y UPDATE. Dado que estamos tratando con Slony-I, no tiene un mecanismo integrado para filtrar DML mientras los reproduce en el nodo esclavo, aunque ha recopilado todos los eventos del nodo maestro. (AFAIK Mysql, Oracle, SQL Server admiten filtros ).
Para aclarar esto, la forma tradicional de Slony-I mantiene la unicidad de las filas en todos los nodos con su concepto central de que las tablas deben tener claves primarias. En tal diseño de arquitectura, es difícil excluir las declaraciones DELETE/UPDATE, tome un ejemplo de la columna de clave principal "orderid" de la tabla "orders" que tiene una primera declaración INSERT con valor 100 y se ha replicado como primera forma en el nodo esclavo filtrado. Más tarde, se ejecutó una declaración DELETE para "orderid =100" y se eliminó la fila, ahora, si alguna declaración INSERT o UPDATE intenta usar "orderid =100", entonces el nodo esclavo golpea con una violación de clave duplicada y simplemente rompe la replicación.
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
Por lo tanto, la regla de implementación aún no es un problema, uno debe ser extremadamente cauteloso cuando esté en su lugar. En realidad, sin embargo, la aplicación de estos filtros en el nodo esclavo Slony-I es muy frágil, especialmente la aplicación/desarrollador siempre debe tener esto en cuenta, cualquier entrada duplicada de fila mediante INSERTAR O ACTUALIZAR podría interrumpir la replicación.
Como las reglas DML no son posibles solo con Slony-I, podemos hacer uso de PostgreSQL CREATE RULE…ON DELETE/ON UPDATE DO INSTEAD NADA y aplicar esa REGLA en la tabla ALTER TABLE…ENABLE REPLICA RULE para anular la instrucción DELETE/UPDATE. El uso de esta opción requiere mucha disciplina, por lo que puede asegurarse de que su solicitud y los miembros del personal realmente sigan estas reglas.
Para continuar con los pasos, debe tener una configuración lenta, en caso de que necesite configurar, puede consultar mi publicación anterior aquí.
Pasos en el nodo esclavo (Master DB:postgres, Slave DB:demo, Puerto:5432):
1. Detenga los demonios slon
2. Cree la regla ON DELETE y ON UPDATE DO INSTEAD NADA
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. Aplicar REGLA en la mesa
demo=# ALTER TABLE reptest ENABLE REPLICA RULE void_delete;
ALTER TABLE
demo=# ALTER TABLE reptest ENABLE REPLICA RULE void_update ;
ALTER TABLE
4. Iniciar demonios Slon
Ahora, puede notar a continuación que ACTUALIZAR/ELIMINAR no tiene impacto en el nodo esclavo:
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)
Si la instrucción INSERT se ejecuta con el valor 1, interrumpirá la replicación. ¡¡Tenga en cuenta…!!
Recuerde, hay otras formas de completar esta solicitud como dblinks, Triggers como ANTES DE ELIMINAR... devolver el valor NULL de la función, pero creo que la forma más eficiente sería usar RULE/ENABLE REPLICA RULE cuando esté trabajando con la replicación de Slony.
A estas alturas, es posible que haya leído muchos blogs sobre la nueva característica de las ranuras de replicación de decodificación lógica en PostgreSQL 9.4, espero que en el futuro pueda incluir el concepto de filtro DML en Slave.
Gracias por visitarnos.
