Existe um aplicativo de livraria da faculdade online onde muitos alunos podem comprar livros. Toda vez que um aluno faz logon, ele mostra uma lista de sugestões com base em seu histórico de compras anterior. O SQL Server que armazena os dados do cliente está em Seattle, mas esses alunos estão fazendo logon de todo o mundo. Portanto, o desempenho pode ser prejudicado e aqueles que estão mais distantes na WAN podem enfrentar um atraso nas consultas.
Em vez de fazer com que os alunos mais distantes sofram tempos de carregamento de página lentos, a replicação pode ser usada para copiar e manter objetos de banco de dados em vários sites e sincronizar posteriormente para que a consistência seja mantida. Cada site mantém a parte do banco de dados que contém os dados mais relevantes para eles e usados com mais frequência. Agora, cada aluno pode adquirir livros no site, e os dados serão sincronizados posteriormente.
Como funciona a replicação de dados
Existem vários componentes de servidor e eles assumem funções diferentes para implementar a replicação. Uma função de editor é uma instância de banco de dados na qual reside a origem dos dados e contém objetos projetados como artigos de replicação. Esses artigos são agrupados e publicados em uma publicação para que os dados sejam replicados como uma unidade. O editor pode ter várias publicações.
Uma função de distribuidor é uma instância de banco de dados que contém os bancos de dados de distribuição. Cada publicador é mapeado para um único banco de dados de distribuição que armazena os dados replicados do publicador que devem ser passados ao assinante. O distribuidor pode ser configurado como um distribuidor local, o que significa que uma única instância de servidor pode servir nas funções de editor e distribuidor. Se um distribuidor estiver configurado em servidores separados, ele será chamado de distribuidor remoto.
Uma função de assinante é a(s) instância(s) que recebe os dados replicados assinando as publicações. O assinante não é limitado e está qualificado para receber dados de vários editores, e os objetos podem ser atualizados dependendo do tipo de replicação. Se aplicável, o editor receberia essas alterações do assinante e republicaria os dados.
Em geral, o assinante recebe as alterações nos dados de duas maneiras:por meio de assinatura push ou assinatura pull. A diferença está em qual componente do servidor executa as atualizações. Com push, o distribuidor empurra ou atualiza diretamente o banco de dados de assinantes. Com o pull, o assinante faz check-in com o distribuidor para ver se houve alguma alteração e ele mesmo realizará a atualização.
Três tipos de replicação de dados
Para implementar a replicação, vários agentes são usados para realizar os trabalhos associados à cópia das alterações, acompanhamento das alterações e distribuição dos dados. Quais agentes são necessários depende do tipo de replicação usado. Existem três tipos principais de replicação.
1. Replicação de instantâneo
A replicação de instantâneo é o tipo mais simples de replicação de dados e é usada se os dados não forem alterados com tanta frequência ou se pequenos volumes de dados precisarem ser replicados. Por exemplo, se houver tabelas que não são muito atualizadas, os Snapshot Agents podem ser usados para copiar todo o banco de dados uma vez ou repetidamente de acordo com uma programação. Em seguida, um Agente de Distribuição é responsável por transferir esses arquivos para o assinante.
Essa técnica requer pouca manutenção porque o que é distribuído é um instantâneo dos dados em um momento específico. Além disso, não há necessidade de monitorar as alterações porque sempre que um assinante recebe uma atualização, ele substitui a cópia inteira dos dados.
Infelizmente, copiar um banco de dados inteiro pode contribuir para alta latência ou mais esperas do que o desejável. A geração de instantâneos requer a retenção de bloqueios em objetos. Não é conveniente se os dados forem alterados com frequência e provavelmente afetarem o desempenho, por exemplo, se o editor tiver muitas atividades de inserção, atualização e exclusão.
Além de usar os Snapshot Agents para criar os snapshots, as replicações transacionais também aproveitam os Log Reader Agents executados no distribuidor. O Log Reader Agent lê os logs de transações do banco de dados do editor e entrega apenas as alterações marcadas em vez de esperar em um banco de dados inteiro. Isso fornece flexibilidade porque permite que você decida quanto do banco de dados publicar (por exemplo, uma coluna). Em seguida, o Distribution Agent move as transações para os assinantes e onde ele é executado acomodará as estratégias de assinatura push e pull, respectivamente.
2. Replicação transacional
A replicação transacional padrão implica que os dados no assinante sejam somente leitura. No entanto, existem diferentes tipos de publicação que permitem que sejam feitas modificações no assinante. Se essas alterações forem feitas, elas poderão ser retransmitidas ao editor para republicação. O Queue Reader Agent é usado para replicação transacional bidirecional e lerá as alterações da fila e as aplicará no editor.
A replicação transacional é muito benéfica em um ambiente de servidor para servidor em que as alterações podem ser feitas no editor e no assinante em tempo real — por exemplo, dados em tempo real relacionados a quais voos estão atualmente disponíveis para uma companhia aérea. Não faz sentido usar a replicação de instantâneos nesse caso porque as atualizações geralmente são sincronizadas uma vez por dia ou de acordo com um agendamento.
3. Replicação de mesclagem
A replicação de mesclagem é como a replicação de transação, mas permite que as atualizações no assinante e no editor sejam mescladas. Muitos assinantes podem ficar offline, fazer atualizações nos dados em momentos diferentes e depois voltar a ficar online e sincronizar essas alterações posteriormente.
Esse tipo de replicação provavelmente será usado em ambientes de servidor para cliente, como clientes móveis. Assim como a replicação de instantâneo e transação, o instantâneo inicial é criado pelo Snapshot Agent, mas o Merge Agent rastreará as alterações e resolverá conflitos com acionadores. Se vários assinantes estiverem atualizando as mesmas linhas, eles poderão causar um problema. Portanto, a resolução de conflitos precisa ser contabilizada.
