Explorar o Replicação de dados da instância

Replicação de dados da instância (IDR) fornece uma replicação do tipo um para muitos, que permite que uma instância propague dados entre diferentes departamentos e unidades de negócios para mantê-los sincronizados.

IDR também é compatível com replicação bidirecional. A replicação bidirecional permite copiar dados de uma instância do produtor para uma instância do consumidor e de uma instância do consumidor de volta para a instância do produtor.

Benefícios

• Os dados são replicados automaticamente para uma ou mais instâncias.
• Os dados podem ser modificados e mapeados para qualquer tabela e coluna de tabela em outras instâncias. Por exemplo, você pode modificar e mapear colunas da tabela para localizar dados para diferentes localidades.
• Os dados atualizados em instâncias do consumidor podem ser replicados para a instância do produtor.

  Dados, como solicitações associadas a problemas, podem ser copiados para instâncias do consumidor para uso de terceiros. O terceiro pode atualizar o problema na instância do consumidor. Os dados podem ser atualizados na instância do produtor.

• As regras de negócios podem acionar fluxos de trabalho pós-replicação, como a geração de notificações ou a validação da replicação.
• Os dados em trânsito durante uma falha são recuperáveis.

Como o Replicação de dados da instância funciona

Use o plug-in Replicação de dados da instância (com.glide.idr) para replicar atualizações de dados em uma instância, chamada de instância produtora, para uma ou mais instâncias, chamadas de instâncias consumidoras.

Ao configurar um conjunto de replicação produtora, você pode especificar as tabelas e colunas da tabela na instância produtora para replicar. Ao configurar um conjunto de dados consumidor, você pode especificar as tabelas e colunas de tabela nas instâncias consumidoras que recebem os dados do conjunto de replicação produtora.

Em seguida, você ativa os conjuntos de replicação produtora e consumidora para ativar a funcionalidade IDR. Os dados atualizados em um conjunto de replicação produtora atualizam automaticamente os dados correspondentes nos conjuntos de replicação consumidora.

A sincronização dos conjuntos de replicação produtora e consumidora requer que você faça um download único (chamado propagação) de todos os dados do conjunto de replicação produtora para as instâncias consumidoras.

Você pode iniciar solicitações de propagação em uma instância do consumidor quando ativar um conjunto de replicação consumidora. A partir da versão Rome, você pode usar um recurso de critério de filtro (chamado propagação parcial) para restringir o número de registros propagados. Use a propagação parcial para dividir trabalhos grandes em trabalhos menores quando tiver um número grande de registros para duplicar.

Após a propagação, a replicação envolverá somente atualizações de dados. Uma trilha de auditoria contém um histórico dessas atualizações de registro.

Por padrão, os dados de tabela em uma instância do produtor vão para tabelas com o mesmo nome nas instâncias do consumidor. Transformação é o processo de replicação de dados do produtor em tabelas ou colunas de tabela que têm um nome diferente nas instâncias do consumidor.

IDR adaptadores modificam os dados antes de armazená-los nas instâncias do consumidor. Os adaptadores executam operações matemáticas e de cadeia de caracteres, como converter uma moeda para outra ou converter um fuso horário para outro.

Figura 1. Visão geral IDR

Aviso:

IDR substitui dados em instâncias e pode replicar dados confidenciais. Evite a possível perda e exposição de dados testando sua implementação de IDR em um ambiente de pré-produção. Consulte a privacidade de dados no IDR para mais informações.

Conjuntos de replicação legados e V2

IDR é compatível com conjuntos de replicação legados e V2. A partir da versão Washington DC, não é mais possível criar conjuntos de replicação legados.

• Os conjuntos de replicação legados usam uma implementação de transporte e entrega de mensagens ServiceNow do Kafka criada antes da versão Utah. Todos os conjuntos de replicação criados antes da versão Utah são considerados legados.
• Os conjuntos de replicação V2 usam ServiceNow Serviço de envio de mensagens Hermes para transporte e entrega de mensagens do Kafka. O Serviço de envio de mensagens Hermes é um recurso Now Platform que permite que IDR replique dados com mais rapidez e em escala.

Os conjuntos de replicação do produtor legados são compatíveis somente com os conjuntos de replicação do consumidor legados. De maneira semelhante, os conjuntos de replicação do produtor V2 são compatíveis somente com os conjuntos de replicação do consumidor V2.

Você pode criar novos conjuntos de replicação V2 ou fazer upgrade de conjuntos de replicação legados existentes para V2. Consulte Atualizando conjuntos de replicação legados para V2 em Replicação de dados da instância.

Limitações de IDR e quando não usar IDR

• Não use IDR para clonar instâncias.

  IDR não replica tabelas de metadados, tabelas de metadados secundárias e a maioria das tabelas de usuário e do sistema. IDR foi projetado para replicar dados, não para clonar instâncias. Por exemplo, a tabela Arquivo de aplicação [sys_metadata] e tabelas que estendem [sys_metadata] (incluindo as tabelas Regras de negócios [sys_script], Catálogo [sc_catalog] e Fluxo de trabalho [wf_workflow]) são excluídas e não podem ser replicadas. Para obter detalhes sobre clonagem, consulte System clone.

• Evite usar IDR para replicar uma série de anexos grandes regularmente. Se você precisar incluir anexos com mais de 10 MB regularmente, monitore IDR para garantir que o tempo de atraso não exceda as expectativas.
• Evite replicar tabelas do CMDB. Se você determinar que as tabelas do CMDB devem ser replicadas, use 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.
• Não é possível replicar os campos Edge Encrypted, Column Level Encryption (CLE) e Senha (criptografada em duas vias).
• Limitações para replicar registros atualizados:
  • O tamanho máximo do registro é 32 MB.
  • IDR O oferece suporte à replicação de aproximadamente 1 milhão de registros por dia.
• Limitações para propagação de registros:
  • A propagação de replicação não deve levar mais de sete dias para ser concluída.
  • A propagação inicial das tabelas não deve exceder 3 milhões de registros por conjunto de replicação.
  Nota:

  Para superar essas limitações, reduza o número de tabelas na solicitação de propagação, reduza o tamanho dos registros ou use a propagação parcial.