Para cumprir esse requisito, devemos criar algum tipo de filtro como TRIGGERs/RULEs no Slave Node para evitar a retransmissão de instruções DELETE e UPDATE. Como estamos lidando com o Slony-I, ele não possui um mecanismo embutido para filtrar DMLs enquanto os reproduz no nó escravo, embora tenha reunido todos os eventos do nó mestre. (AFAIK Mysql, Oracle, SQL Server suporta filtros ).
Para esclarecer isso, a maneira tradicional do Slony-I mantém a exclusividade das linhas em todos os nós com seu conceito central de tabelas que devem ter chaves primárias. Em tal projeto de arquitetura, é difícil excluir instruções DELETE/UPDATE, tome um exemplo de coluna de chave primária “orderid” da tabela “orders” que tem uma primeira instrução INSERT com valor 100 e foi replicada como primeira forma no Slave Node filtrado. Mais tarde, uma instrução DELETE executada para “orderid =100” e linha excluída, agora, se qualquer instrução INSERT ou UPDATE tentar usar o “orderid =100”, o nó escravo atingirá a violação de chave duplicada e simplesmente interromperá a replicação.
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
Assim, a implementação da regra não é um problema, mas deve-se ser extremamente cauteloso quando estiver em vigor. Na realidade, no entanto, a aplicação desses filtros no nó escravo Slony-I é muito frágil, especialmente o aplicativo/desenvolvedor deve sempre ter isso em mente, qualquer entrada duplicada de linha por INSERT OU UPDATE pode interromper a replicação.
Como as regras DML não são possíveis sozinhas com o Slony-I, podemos usar o PostgreSQL CREATE RULE…ON DELETE/ON UPDATE DO INSTEAD NOTHING e aplicar essa RULE na tabela por ALTER TABLE…ENABLE REPLICA RULE para anular a instrução DELETE/UPDATE. Usar essa opção exige muita disciplina, para que você possa garantir que sua inscrição e os membros da equipe realmente sigam essas regras.
Para continuar com as etapas, você deve ter uma configuração desleixada, caso precise configurar, consulte meu post anterior aqui.
Etapas no nó escravo (DB mestre:postgres, DB escravo:demo, porta:5432):
1. Pare daemons slon
2. Crie a regra ON DELETE e 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. Aplicar REGRA na mesa
demo=# ALTER TABLE reptest ENABLE REPLICA RULE void_delete;
ALTER TABLE
demo=# ALTER TABLE reptest ENABLE REPLICA RULE void_update ;
ALTER TABLE
4. Inicie os daemons do Slon
Agora, você pode notar abaixo que UPDATE/DELETE não tem impacto no 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)
Se a instrução INSERT for executada com valor 1, ela interromperá a replicação. Fique atento…!!
Lembre-se, existem outras maneiras de preencher essa solicitação como dblinks, Triggers como BEFORE DELETE…retorna o valor NULL da função, mas acredito que a maneira mais eficiente seria usar RULE/ENABLE REPLICA RULE quando você estiver trabalhando com replicação Slony.
Até agora você deve ter lido muitos blogs sobre o novo recurso de slots de replicação de decodificação lógica no PostgreSQL 9.4, espero que no futuro possa incluir o conceito de DMLs de filtro no Slave.
Obrigado pela visita.
