Preparando para Replicação de dados da instância
Antes de configurar Replicação de dados da instância (IDR), analise as tabelas e colunas nas instâncias do produtor e do consumidor para replicar dados com sucesso.
Preparando suas instâncias
Reduza a latência garantindo que as instâncias do produtor e do consumidor estejam na mesma região geográfica e pertençam ao mesmo cliente. Você pode replicar dados entre instâncias em diferentes regiões geográficas. No entanto, a latência de replicação pode ocorrer quando as instâncias estão localizadas em datacenters em regiões separadas.
Decidindo quais tabelas serão replicadas
Antes de criar um conjunto de replicação do produtor, decida quais tabelas replicar. Evite replicar tabelas do sistema (tabelas com um prefixo sys_). Ao replicar tabelas do sistema (como sys_user, sys_user_group ou sys_user_grmember) com dados na instância do consumidor, poderão ocorrer falhas de inserção e atualização durante a replicação. Se você decidir replicar essas tabelas, poderá ter mais trabalho posteriormente para limpá-las.
Evite a replicação contínua de CMDB tabelas. Replicar CMDB dados conforme ocorrem mudanças pode criar problemas de desempenho ou consequências imprevistas com a replicação devido ao número de registros envolvidos. Se você precisar replicar tabelas CMDB, considere programar a replicação ou usar condições para restringir a contagem de registros replicados e garantir que todas as colunas necessárias sejam incluídas no conjunto de replicação.
Para obter uma lista de tabelas para evitar a replicação, consulte Tabelas excluídas em Replicação de dados da instância.
Analisando hierarquias de tabelas
Consulte Preservando a hierarquia de tabelas em Replicação de dados da instância.
Analisando relacionamentos de tabela
Para cada tabela que você deseja replicar, determine se ela tem campos de referência que apontam para outras tabelas. Se você estiver replicando uma tabela com um campo de referência que aponta para outra tabela, mas não incluir essa tabela no conjunto de replicação, o campo de referência ficará vazio no registro da instância do consumidor. A replicação de relacionamentos de tabela mantém a integridade dos dados e garante que os campos de referência sejam preenchidos no consumidor conforme esperado.
Organizando conjuntos de replicação
Como parte da fase de planejamento, determine como quer organizar seus conjuntos de replicação e as tabelas contidas neles.
- Crie um único conjunto de replicação para cada tabela. Essa opção demanda mais configuração e gestão de tempo, mas permite que você pause a replicação de uma única tabela sem afetar outras tabelas.
- A replicação é realizada em paralelo, usando vários trabalhos.
- As métricas de rendimento são mais fáceis de rastrear com conjuntos de replicação separados.
- Quando ocorre um erro, a replicação de uma só tabela é afetada, e não a de todas as várias tabelas.
- Crie um conjunto de replicação para um grupo de tabelas relacionadas. Essa opção é mais fácil de configurar e gerenciar, mas a supervisão e os possíveis problemas afetam todas as tabelas do grupo.
- Se você precisar encontrar informações sobre o status de replicação, o nome lógico usado para este conjunto de replicação pode ser mais fácil de encontrar e entender em comparação com o uso de conjuntos de replicação distintos para cada tabela.
- Se você quiser pausar a replicação, poderá fazer isso para todo o grupo de tabelas pausando a replicação de um conjunto.
- Se ocorrer um problema de replicação em uma tabela e a replicação parar, isso interromperá a replicação para todas as tabelas no conjunto.
Se você decidir agrupar tabelas em um único conjunto de replicação, tente limitá-lo a cinco ou menos tabelas. Se você tiver mais de cinco tabelas para replicar, use vários conjuntos de replicação com cinco ou menos tabelas em cada um.
Decidindo quais colunas serão replicadas
Para cada tabela que você quer replicar, decida quais colunas serão incluídas. Evite incluir cada coluna do seu conjunto de replicação por padrão. Em vez disso, decida quais colunas são necessárias e exclua quaisquer colunas sys_ ou outras que sejam atualizadas por scripts automaticamente.
Por exemplo, se você incluir uma coluna atualizada automaticamente pelo sistema com frequência, IDR poderá replicar os dados mais vezes do que o necessário. Quando o sistema replica esses dados, ele pode afetar negativamente a assinatura de capacidade. Verifique periodicamente o painel de licença do IDR e detalhes de uso para monitorar a contagem de mensagens gerada pelo produtor.
Preparando tabelas de destino na instância do consumidor
Por padrão, IDR usa o campo sys_id de um registro como o valor de pesquisa para manter os dados sincronizados entre a instância do produtor e a do consumidor. Se a tabela de destino tiver dados ou registros de importações de dados anteriores, os valores de sys_id no consumidor não corresponderão aos sys_ids da instância do produtor.
Sempre considere a instância do produtor como a fonte de verdade. Para alcançar os resultados de replicação ideais, siga estas diretrizes:
- Faça da instância do produtor a fonte de dados exclusiva da instância do consumidor.
- Antes da replicação, verifique se a tabela de destino na instância do consumidor está vazia. O ideal é que os registros iniciais na instância de destino sejam criados a partir de dados enviados exclusivamente pelo produtor por meio de um conjunto de replicação ou um clone.
- Certifique-se de que não haja outras importações ou atualizações de dados em andamento para as tabelas de destino na instância do consumidor após o início da replicação.
Por exemplo, se os usuários do LDAP forem importados para a instância do consumidor usando uma fonte de dados diferente, os sys_ids desses registros não corresponderão aos valores do sys_id na instância do produtor. Nesse cenário, os registros do usuário da tabela de destino no consumidor não são atualizados e são criados registros duplicados.
Quando isso não puder ser evitado, limpe as tabelas na instância do consumidor antes da replicação. Você deve excluir os registros na tabela de destino ou garantir que os valores de sys_id no produtor e no consumidor sejam iguais.
Como alternativa, você pode usar um campo de aglutinação personalizada para identificar registros exclusivos (em vez de a coluna sys_id padrão) para replicação. Use uma coluna Aglutinar personalizada quando os registros na instância do consumidor tiverem um sys_id diferente dos mesmos registros na instância do produtor. Para mais informações sobre como usar uma aglutinação personalizada, consulte Aglutinação personalizada.
Revisando regras de negócio
Você pode usar regras de negócios para acionar fluxos de trabalho após a replicação, como enviar uma notificação ou validar os dados replicados. Revise todas as regras de negócios na instância do consumidor que possam impedir o usuário de idr.system de inserir, atualizar ou excluir registros na tabela de destino.
Se ocorrerem falhas relacionadas a regras de negócio, elas serão exibidas no tabela na instância do consumidor. Exiba o campo Mensagem de erro para detalhes sobre o script que está causando a falha.
Com a replicação bidirecional, os registros criados na instância do produtos são replicadas na instância de um consumidor e vice-versa. Quando o registro é inserido na instância do consumidor e aciona uma regra de negócio que atualiza o registro, essa atualização não é replicada de volta na instância do produtor.
Analisando ACLs
Analise as ACLs em vigor na tabela de destino na instância do consumidor para garantir que IDR possa replicar os dados com sucesso. Confirme se o usuário do idr.system tem as funções apropriadas para a tabela de destino.
Se ocorrerem falhas relacionadas a ACLs, elas serão exibidas no tabela na instância do consumidor. Exiba o campo Mensagem de erro para detalhes sobre a ACL que está causando a falha.
Analisando políticas de dados
Analise todas as políticas de dados em vigor na tabela de destino na instância do consumidor para garantir que IDR possa replicar os dados com sucesso. Confirme se os dados que você está replicando estão de acordo com a política de dados.
Se ocorrerem falhas relacionadas a políticas de dados, elas serão exibidas no tabela na instância do consumidor. Exiba o campo Mensagem de erro para detalhes sobre a política de dados que está causando a falha.