Júlio Battisti Livros e Cursosa sua sala de aula na internet

Quando formos planejar um esquema de replicação, como forma de manter sincronizadas duas ou mais cópias de um determinado conjunto de dados, devemos levar em consideração diversos fatores. A seguir descrevemos quais são estes fatores.

• Latência: É o tempo que demora para que dois conjuntos de dados estejam sincronizados. Com a replicação, não temos como garantir que as diversas réplicas estejam exatamente iguais o tempo todo. À medida que alterações vão sendo introduzidas em uma réplica, demora um certo tempo (latência), até que estas alterações sejam propagadas para as demais réplicas. Devemos levar em consideração qual o nível de latência aceitável para cada caso: minutos, horas, dias, etc.

Existe uma técnica conhecida como “Transações Distribuídas – Distributed Transactions”. Com esta técnica à medida que uma transação é aplicada em um Banco de Dados, a mesma transação é, automaticamente, aplicada nas demais réplicas do Banco de Dados. Desta forma é como se a alteração estivesse sendo feita, ao mesmo tempo, em todos os Bancos de Dados. A grande vantagem desta técnica é que as diversas cópias estão perfeitamente sincronizadas, o tempo todo. O grande problema com Distributed Transactions é quando um dos servidores, que contém uma das cópias, está fora do ar. Neste caso não temos como aplicar as transações neste servidor. Com isso, quando o servidor voltar a estar disponível, precisamos utilizar uma outra técnica para sincronizá-lo com os demais, antes que ele volte a ser colocado online, em produção.

• Autonomia da réplica: Este fator tem a ver com a possibilidade do servidor em que está uma réplica poder continuar em funcionamento, caso o servidor perca o contato com os demais servidores. A perda de contato pode ser ocasionada, por exemplo, devido a uma falha na linha de comunicação de dados. No caso de replicação, o servidor pode continuar funcionando sem problemas. Quando a comunicação for restabelecida, os dados passarão a ser sincronizados, de acordo com a programação da replicação. Imagine no caso da empresa ABC, que tem escritórios em São Paulo, Rio de Janeiro, Belo Horizonte e Porto Alegre. Um dos escritórios não pode parar de aceitar pedidos porque houve uma falha na linha de comunicação. O escritório continua aceitando pedidos e, quando a linha de comunicação for restabelecida, os dados são replicados com a base consolidada.
• Conflitos de atualização: No caso de diversas réplicas, em que os dados podem ser alterados em qualquer delas, podemos ter uma situação em que o mesmo registro foi alterado em duas réplicas diferentes. Ao replicar este registro, teremos um conflito de replicação. O SQL Server tem alguns mecanismos automáticos para resolução deste tipo de conflitos.
• Velocidade dos links de WAN: Este é um fator de grande importância. Replicação implica em informação sendo enviadas pela rede. Devemos fazer uma estimativa do volume de dados a ser replicados e comparar com a capacidade do link disponível. Isto evita que, devido à replicação, o link fique sobrecarregado, impedindo que outras aplicações críticas, como por exemplo e-mail, tenham um desempenho satisfatório.