Replicação de Banco de Dados

08/01/2009

 

Amigos,

Segue um post de um trabalho que entreguei recentemente na Pós, espero que lhes possam ser útil. Fiquem a vontade para comentar.

Replicação de Banco de Dados

Para que serve?

Para duplicar e fazer múltiplas cópias gerenciadas de dados com objetivos de:

Descentralizar “aplicações”, viabilizar Hot-backup de servidores de banco de dados, proporcionar o Balanceamento de Carga, viabilizar arquiteturas e soluções de Data Warehousing e viabilizar a Integração de sistemas heterogêneos.

Por que usar?

Devemos utilizar o recurso de replicação de dados por ser este o único recurso quando temos a necessidade de replicar um ou mais banco de dados ou simplesmente alguns de seus objetos e sincronizar-los de acordo com uma necessidade de negócio.
Lançamos mão de uma solução de replicação quando visamos ganho de performance, alta disponibilidade, autonomia de unidades de negócios (distribuída entre filiais e matriz), ou sincronismos de bases desconectadas ex: Dispositivo Móvel  com Base Corporativa.

O que é replicação de dados?

Replicação de dados é o processo de copiar e manter objetos de banco de dados em vários SGDB’s que formam um banco de dados distribuído. A replicação aumenta a performance e a disponibilidade das aplicações por existir mais de uma alternativa para se acessar um dado.
Com a replicação de dados todas as cópias de uma tabela que é parte de um ambiente replicado pode ser consultadas ou mesmo atualizadas por uma aplicação. Os SGDB’s que formam o ambiente replicado automaticamente trabalham para convergir os dados de todas as réplicas de tabelas, garantindo assim a consistência e integridade transacional do ambiente.

Quais são os Modelos mais comuns de replicação?

Modelo – Replicação Mestre/Escravo
 
Neste modelo cada objeto possui um dono, a cópia primária é aquela que é dona do objeto, nela podem ser realizadas leituras e atualizações. As demais cópias são secundárias, nelas somente poderão ser realizadas leituras, usualmente se tem mais de uma cópia secundária.
Os “Nós Mestres” são aqueles onde só existem cópias primárias ao passo que os “Nós Escravos” são aqueles onde só existem cópias secundárias. Existem também os “Nós Mestre-Escravo” sendo que estes possuem cópias primárias e secundárias. Um problema deste modelo é que qualquer falha em um “Nó” mestre impede que sejam realizadas as atualizações nos demais “Nós”

Modelo – Replicação em Grupo

Neste modelo todas as cópias são donas dos objetos, de forma que as leituras e gravações podem ser realizadas em qualquer uma delas. A vantagem deste modelo esta no fato que a falha de um “Nó” não impede o correto funcionamento dos demais.

Quais são as Estratégias de Propagação existente?

Replicação síncrona

Esta se dá quando realizamos a atualização em uma tabela que possuí cópias, o SGBD realiza a atualização em todas as réplicas dentro da mesma transação. A transação só termina quando todas as cópias do objeto tiverem sido atualizadas. O sincronismo se dá quando todas as réplicas são atualizadas dentro da mesma transação considerando a propriedade da atomicidade.

Replicação Assíncrona

Esta se dá quando a atualização solicitada pelo cliente é realizada apenas em um “Nó” e somente após que a transação em que esta atualização está inserida termina, são disparadas transações de atualização nos vários “Nós” que contém as réplicas. Neste caso é disparada uma transação para cada uma das réplicas não atualizadas.

Replicando Banco de Dados – Abordagem em SQL Server

A ferramenta de replicação do SQL Server permite que a estrutura e os dados de uma determinada base sejam disseminados para outros meios, tais como outros servidores ou dispositivos móveis rodando SQL Server Compact Edition.

Existem diversos cenários onde a replicação é a melhor e mais simples solução para algum problema específico, entre estes cenários citamos dois casos distintos:

Processamento Offline: Se você deseja manipular dados em uma máquina ou dispositivo móvel não conectado, a replicação pode ser utilizada para que o sincronismo seja feito apenas em momentos onde há conectividade.

Redundância: A ferramenta de replicação permite que você construa uma base “espelhada” da base de sua aplicação, o que permite que em algum momento de indisponibilidade ela tome o lugar da base de “produção” sem maiores dificuldades.

Em qualquer cenário de replicação existem dois principais componentes, os Editores                  ( Publishers) e ao Assinantes (Subscribers).

Os Editores disponibilizam seus dados para outros servidores através de Artigos (Articles), um artigo é um objeto em uma base de dados, como por exemplo, VIEWS, TABELAS, e etc.

Os Assinantes consomem os dados dos editores, eles que recebem as atualizações quando há alguma modificação na base Editora. Lembrando que nada impede que uma base de dados seja Assinante e Editora ao mesmo tempo, na verdade isso é freqüentemente utilizado.

Esse processo de “meio de campo” entre Editores e Assinantes é feito pelos Agentes (Agents).

O SQL Server suporta três diferentes tipos de replicação, Snapshot, Transactional e Merge Replication.

Snapshot Replication: Como o próprio nome já sugere, ele simplesmente tira uma “foto” da base de dados replicada e compartilha essa “foto” com os seus Assinantes, em um processo longo e que consome muitos recursos do servidor, afinal é uma cópia completa de todos os artigos da Publicação, por esse motivo esse tipo de replicação não é utilizado em uma base de dados que sofre freqüentes alterações.

Transactional Replication: A replicação transacional é bem mais flexível do que a Snapshot, quando se trata de uma base de dados que sofre constantes alterações, nesse tipo de replicação o seu Agente monitora a base Editora esperando por alterações e transmite somente essas alterações para os assinantes, de maneira muito mais otimizada e rápida do que a anterior.

Merge Replication: Permite que o Assinante e o Editor efetuem alterações independentes na base de dados, ambas as entidades podem trabalhar desconectadas. No momento do sincronismo (com as bases conectadas obviamente) o Agente de Mesclagem(Merge Agent) checa as alterações feitas na Publicação e em cada um dos Assinantes e mescla as alterações de maneira que os dados fiquem solidificados. Entretanto neste processo de mesclagem podem ocorrer conflitos por diversos motivos, esses conflitos podem ser solucionados facilmente com um algoritmo de resolução de conflitos que determina os dados apropriados a serem mantidos na base. Este tipo de replicação é utilizado freqüentemente em bases de dados de dispositivos móveis os quais não estão constantemente conectados ao Editor.

Anúncios