Universidade Federal de Santa Catarina

Universidade Federal de Santa Catarina
Centro Tecnológico – CTC
Curso de Sistemas de Informação
Disciplina Projetos I
Implementação de replicação assíncrona entre bancos de dados heterogêneos
Heliomar Quadros Lorêdo
Lindemberg Naffah Ferreira
Versão resumida por Michael Molina
Florianópolis 15 de outubro de 2007
Introdução
Devido ao crescente desenvolvimento de aplicações distribuídas que visam a atender
eficientemente um número cada vez maior de usuários, e o fato destas aplicações
possuírem passos de uma mesma transação em localidades diferentes, faz com que a
sincronização e replicação dos dados seja um requisito em operações de tempo real ou
críticas.
Há várias maneiras de implementar replicação em bancos de dados distribuí dos. É
possível falar-se em replicação síncrona e assíncrona, total ou parcial, procedural ou de
dados, dentre outros critérios possíveis de classificação.
A replicação de bancos de dados heterogêneos, em particular, costuma demandar a
utilização de gateways, ou de ferramentas especí ficas, para sua consecução. Este
trabalhopropõe, valendo-se de técnicas já existentes e da teoria de bancos de dados
distribuí dos, uma forma de implementação que viabilize a replicação assí ncrona entre
SGBD heterogêneos, sem que seja obrigatória a presença de um gateway ou de alguma
ferramenta de replicação nativa de algum dos SGBD envolvidos, ou comercializada por
terceiros.
Arquitetura proposta
Se considerarmos o uso de replicação assí ncrona entre bancos de dados
heterogêneos, conforme definido na solução de BDD para o cenário da Figura 1, será
necessário utilizar um gateway que possibilite a comunicação entre os SGBD ou um
software de replicação entre bancos heterogêneos. Propõe-se aqui a escolha de uma
combinação apropriada de técnicas para replicação, a fim de eliminar a necessidade de
um gateway ou de alguma ferramenta, nativa ou de terceiros, para implementar
replicação assíncrona entre bancos de dados heterogêneos.
Nesta arquitetura propõem-se o aperfeiçoamento da relação mestre-escravo entre
servidores e clientes, o mestre não seria o único site onde seria possível realizar
atualizações. Na verdade, seria possível efetuar modificações no site mestre, da mesma
maneira que em qualquer outro. Porém, ele seria o responsável por controlar as
replicações e também o único detentor de réplicas de todos os fragmentos envolvidos.
A implementação desta arquitetura é composta de um conjunto de componentes e
passos descritos a seguir.
AGENDA: tabela que armazena a relação entre as transações presentes na fila
de transações do mestre e os sites nos quais elas devem ser aplicadas. Indica quais sites
devem receber quais transações.
ATUALIZA MESTRE: conjunto de triggers implementados na tabela “fila de
transações” localizada no mestre; responsável por aplicar, no mestre, as transações
efetuadas nos demais sites.
BANCO DE DADOS LOCAL: banco de dados onde são armazenados os dados
do negócio. Pode haver um ou mais em cada site presente na aplicação.
CAPTURA: componente responsável por capturar as transações provenientes da
aplicação, aplicar no banco local e, caso seja uma operação que deve ser replicada,
armazenar na fila de transações mantendo a ordem original de sua execução.
CATÁLOGO DE REPLICAÇÃO: banco de dados, presente apenas no servidor
mestre, que contém os dados sobre a replicação; armazena quais são os sites envolvidos,
quais as réplicas presentes em cada um dos sites, o histórico de falhas e sucessos
durante a distribuição de dados, qual o atraso de propagação configurado para cada site,
quais ações devem ser tomadas em caso de falha, etc.
ESCALONA PROPAGAÇÕES: componente responsável por popular a tabela
denominada agenda; a partir de consultas ao catálogo de replicação, com o
conhecimento da distribuição das réplicas dos fragmentos pelos sites e a partir do uso de
triggers, grava na agenda a indicação dos sites que devem receber as transações no
momento em que se conectarem para sincronizar os dados.
EXECUTA SNAPSHOT: componente executado quando um site escravo não
sincroniza os dados com o mestre por tempo muito superior ao configurado; busca, no
banco de dados local do mestre, os valores atuais de todos os fragmentos que devem ser
replicados para o escravo que está realizando a sincronização em momento indevido;
utilizado, também, no momento em que um novo site escravo ingressa no esquema de
replicação, promovendo a primeira carga de dados desse novo site.
FILA DE TRANSAÇÕES - FT: tabela que armazena as transações que serão
replicadas para outros sites.
FILA DE TRANSAÇÕES REPLICADAS - FTR: tabela que armazena as
transações originadas de outros sites e que deverão ser aplicadas localmente.
PROPAGA: componente responsável por transferir o conteúdo da FT do site
onde o dado foi atualizado para a FTR dos sites escravos que receberão a sua réplica;
transfere, também, o conteúdo da FT dos sites escravos para a FT do site mestre.
Segue o esquema abaixo:
A interação destes componentes em passos pré-definidos estabelecem o processo de
replicação em bancos de dados distribuídos de forma a garantir a integridade dos dados.
A definição destes elementos visa garantir a interação modular, independente e atômica
entre as várias etapas do processo.