A replicação por escopo é uma configuração opcional do replicador que permite com que alguns nodes não recebam informações que sejam de interesse específico de outros nodes. Isso pode ser utilizado em cenários como, por exemplo:
Bases de filiais
Empresas franqueadas
Bases instaladas no ambiente de vendedores/representantes específicos
Fluxo normal
Na replicação por escopo, cada registro de cada tabela da base de dados está associado a um único "Escopo". Cada node da rede de replicação está associado a um ou mais escopos. Sempre que um registro for criado, o seu escopo será calculado e informado no dml-log e quando o slave baixar dml-logs de seu master, ele somente receberá registros dos escopos que ele participa.
REGISTRO -> ESCOPO <- ESCOPOS-NODES -> NODES-REPLICACAO
A configuração da replicação por escopo é realizada através de 3 definições:
Definição dos escopos.
Definição dos escopos da cada node.
Definição de como calcular o escopo de um registro de cada entidade.
Definição dos escopos
A definição dos escopos é apenas uma definição de como os escopos serão identificados (nomes). Um escopo pode ser qualquer critério que possa ser utilizado para separar informações entre os nodes. Alguns exemplos de escopo que poderiam ser utilizados:
Estabelecimento: Provavelmente o caso mais comum. Sugere-se utilizar o próprio ID do estabelecimento como identificação do escopo. O uso do ID facilitará o cálculo do escopo de um registro.
Empresa: Parecido com o anterior, mas onde os nodes das filiais teriam acesso aos dados de outras filiais. Note que esse cenário também pode ser resolvido colocando um escopo por estabelecimento e vinculando os nodes das filiais aos respectivos escopos.
Representante: Caso hipotético onde se deseja ter o sistema rodando no ambiente do representante.
Outros escopos podem ser livremente criados. A única condição para definir um escopo é que exista uma forma simples de identifica-lo nos registros das tabelas.
Definição do(s) escopo(s) de um node
Para cada escopo, deveremos indicar quais os nodes que tem acesso ao mesmo. Note que um node pode ter mais do que um escopo e também podemos ter vários nodes com acesso ao mesmo escopo.
Definição do escopo de um registro
Para cada registro na base de dados, teremos que ter uma expressão indicando o escopo do qual este registro participa.
Por uma questão de performance, cada registro da base será de um único escopo. Tabelas globais que não são controladas por escopo e que devem ser distribuídas para TODA a rede de replicação, terão escopo "nulo".
A definição é realizada através de uma expressão configurada em ENTIDADES_SISTEMAS.
Essa expressão pode ser realizada das formas:
Nome de uma coluna: Neste caso o escopo é igual ao de uma coluna da própria tabela. Exemplo: ESTABELECIMENTO_ID
Expressão SQL: O escopo é recuperado através de uma expressão SQL (select). Como parâmetros pode ser utilizada qualquer coluna do registro na convenção de macro. Exemplos: ${id}, ${pedido_id}, etc.
Script: O escopo é calculado através de um script (Groovy, Telescope Script Engine, etc.). Todas as colunas do registro são registradas no contexto do script e podem ser utilizadas como variáveis no mesmo.
Uma coisa importante a ser observada é que qualquer um dos métodos acima são executados na inclusão do registro no log de replicação, ou seja, após a execução da operação na base local. Isso significa que em uma operação de exclusão, por exemplo, o registro não se encontra mais na base de dados e não poderá mais ser acessado por SQL.
Atenção
A versão atual não prevê a mudança de escopo. Isso irá gerar um erro.
Considerações importantes
Escopos na hierarquia dos nodes
Numa estrutura hierárquica, um node nunca poderá ter acesso a um escopo que seu master não tem. Consequentemente, o node "M" (master principal) deverá ter acesso a TODOS os escopos e apenas nodes slaves poderão ter acessos restritos a escopos menores. No caso de nodes no terceiro nível, (M.1.1 por exemplo), somente poderão ter escopos que estejam presentes no seu node superior (M.1).
Mudanças do escopo de um registro
Mudanças de escopo de um registro necessitariam de um tratamento especial que não está implementado atualmente. Note que um registro que alterar do escopo A para o escopo B traria vários impactos:
Remover dos nodes que tem acesso ao A mas que não tem acesso ao B
Inserir nos nodes que tem acesso ao B mas que não tem acesso ao A
Apenas atualizar nos nodes que tem acesso ao B mas que não tem acesso ao A
Isso significa mudar o DDL em várias situações, dependendo de cada caso.
Regras de UK na inclusão de registros
O fato de termos bases sem todos os registros irá necessitar de um cuidado extra na formação das chaves únicas.
Isso significa que qualquer entidade que tenha regras de UK com campos que podem ser informados pelo usuário e que participam de escopos distintos podem gerar erro de UK ao replicar para o master.
Para evitar isso, deve-se tentar manter essas entidades compartilhadas ou criar algum artifício que evite isso.
Mudanças de escopos de um node
Depois do criado, SOMENTE SERÁ PERMITIDO EXCLUIR ESCOPOS DE UM NODE.
SE FOR NECESSÁRIO INCLUIR UM ESCOPO, SERÁ NECESSÁRIO PRIMEIRO RECRIAR UM NODE A PARTIR DE SEU MASTER E DEPOIS EXCLUIR OS ESCOPOS DEIXANDO APENAS OS QUE FOREM DESEJADOS.
Instalação de um novo node - Rotina de limpeza
A instalação de um novo node pode ser feita a partir de um master que tenha os escopos necessários. Uma vez criado, pode-se remover escopos e executar a rotina de limpeza de dados que estiverem fora do escopo.
A rotina de limpeza de escopo pode levar horas e/ou dias para ser executada.
Performance
O modelo acima foi pensado de forma a minimizar problemas de performance no processo de replicação.
Por isso, cada registro faz parte de um único escopo que é calculado/registrado na origem.
Mudanças futuras de modelo
Uma vez que a replicação de escopo for implantada, a equipe técnica deverá se manter atenta à mudanças no modelo de dados que possam impactar nestes cenários. Qualquer nova entidade criada no sistema poderá exigir uma revisão nos algoritmos de escopo das entidades.
Exemplo: Caso seja desenvolvida uma nova entidade que seja separada por estabelecimento, todos os cenários de replicação por escopo onde o escopo seja o estabelecimento terão de ser configurados.
Inclusão de um novo valor nos escopos
Criar um novo escopo será sempre um problema. A criação do escopo e a vinculação com os nodes dever ser sempre realizada ANTES da inclusão de qualquer informação que seja restrita pelo menos.
Por exemplo: Num escopo por estabelecimento, se alguém simplesmente criar um novo estabelecimento, ele não será replicado para nenhum node slave. Assim, caso seja necessário dar acesso ao novo escopo a algum node, os registros deste estabelecimento terão de ser reenviados manualmente.