IV Congresso Brasileiro de Computao CBComp 2004

Banco de Dados

Replicao Assncrona entre Bancos de Dados

Heterogneos: uma abordagem prtica
H. Q. Lordo, UNI-BH, L. N. Ferreira, UNI-BH e G. T.Assis, UNI-BH 1
Resumo-- Este artigo sugere uma abordagem prtica para a
replicao assncrona entre bancos de dados heterogneos. A fim
de cumprir esse objetivo, foi proposta uma arquitetura que
elimina a necessidade de um gateway ou outra ferramenta
qualquer de replicao, nativa ou de terceiros, para levar a cabo
a replicao assncrona entre sistemas de gerncia de banco de
dados heterogneos

Palavras-chaveSistemas de banco de dados, Sistemas de

gerncia de banco de dados distribudos, Bancos de dados
replicados.
Abstract- This paper suggests a practical approach to
asynchronous replication between heterogeneous databases.
Within this aim, an architecture has been proposed which
eliminates the need of a gateway or any other replication tool,
native or third party, to accomplish asynchronous replication
between heterogeneous database management systems.
Index Terms Databases systems, Distributed Database
Management Systems, Replicated Databases.

I. INTRODUO

disponibilidade de meios de comunicao mais fartos

e baratos, somada disseminao do acesso Internet,
propiciaram o desenvolvimento de aplicaes voltadas para o
atendimento das necessidades de usurios geograficamente
dispersos. Uma possvel alternativa para implementar essas
aplicaes so bancos de dados distribudos - BDD. Contudo,
a fim de garantir melhor desempenho e disponibilidade,
usual replicar as bases de dados distribudas, ao menos
parcialmente.
A replicao assncrona de bancos de dados uma
estratgia adequada quando a conexo entre os sites
envolvidos no permanente. Se esses sites estiverem
executando sistemas de gerncia de bancos de dados SGBD
diferentes, ter-se- replicao assncrona de bancos de dados
heterogneos. A replicao de bancos heterogneos, por sua
vez, costuma requerer gateways ou ferramentas especficas
para sua realizao.
Este trabalho prope uma abordagem prtica para a
replicao assncrona entre SGBD heterogneos, dispensando
gateways e ferramentas de replicao, quer estejam elas
disponveis nos SGBD envolvidos ou sejam comercializadas
por terceiros. Para tanto, sero empregadas, to somente,

tcnicas convencionais de replicao, escolhidas de forma

apropriada e capazes de assegurar a integridade das bases de
dados, desde que as aplicaes sejam concebidas para evitar
conflitos. Os objetivos da abordagem proposta so diminuir o
custo de implementao da replicao e permitir maior
flexibilidade, viabilizando, assim, o uso combinado de SGBD
comerciais e no comerciais.
Este trabalho est organizado da forma descrita a seguir. A
Seo II aborda trabalhos relacionados abordagem sugerida,
destacando semelhanas e diferenas entre eles e o que se est
propondo. Na Seo III, prope-se a abordagem prtica de que
trata este artigo. Na Seo IV, apresenta-se um exemplo de
uma aplicao real, relatando resultados do uso desta tcnica
em uma empresa que necessita utilizar bancos heterogneos,
replicados e hospedados em sites que no dispem de conexo
permanente. Por fim, na Seo V, sintetiza-se as sugestes
contidas no trabalho, bem como os resultados obtidos, alm de
comentar as diretrizes para trabalhos futuros.
II. TRABALHOS RELACIONADOS
KEMME & ALONSO [6] desenvolveram uma soluo
denominada Postgres-R para replicao de bancos de dados
envolvendo SGBD de cdigo aberto.
Os autores supracitados propuseram a utilizao de
replicao imediata (eager) em lugar da replicao deferida
(lazy). Sua abordagem inovou, ao definir que as atualizaes
deveriam ser realizadas em cpias shadow privadas, a fim de
verificar consistncias e detectar dependncias entre leituras e
escritas. O uso de cpias shadow viabilizava, tambm, o
agrupamento de escritas em uma nica mensagem, contendo
um nico write set. Essa estratgia permitia solucionar um dos
principais gargalos da replicao imediata (eager), a saber, o
excessivo trfego de mensagens, que limitava a
expansibilidade dessa modalidade de replicao.
O referido trabalho, no entanto, est focado na realizao de
replicao sncrona em redes locais de computadores - LAN.
Nossa proposta, ao contrrio pretende abordar a replicao
assncrona; alm disso, as aplicaes prticas que
pretendemos atacar envolvem, via de regra, redes de longa
distncia - WAN.

1
Heliomar Q. Lordo (heliomar_loredo@hotmail.com), Lindemberg N.
Ferreira
(lnaffah@dcc.ufmg.br)
e
Guilherme
T.
de
Assis
(gtassis@dcc.ufmg.br) so, respectivamente, aluno, professor e coordenador
do curso de ps-graduao em banco de dados do do Centro Universitrio de
Belo Horizonte - UNI-BH, Belo Horizonte, Minas Gerais, 30180-111.

53

IV Congresso Brasileiro de Computao CBComp 2004

A despeito disso, o trabalho de KEMME & ALONSO [6]
utilizava algumas estratgias interessantes para a replicao
em SGBD distribudos, as quais foram incorporadas em nossa
proposta, conforme ser mencionado na Seo III. Uma delas,
guisa de exemplo, envolvia a idia de no replicar leituras,
mas apenas atualizaes de dados. Esse artifcio, presente em
protocolos de replicao primitivos, como read-one/write all,
apresentado
em
BERNSTEIN,
HADZILACOS
&
GOODMAN [3], implica em que as operaes de leitura
sejam realizadas apenas em um site e que nenhuma
informao acerca delas seja trocada entre os sites. Tal
estratgia permite significativa reduo no trfego de rede.
Aumenta, contudo, a complexidade da identificao de
conflitos entre leituras e escritas, uma vez que leituras so
vistas apenas localmente. KEMME & ALONSO [6]
propuseram uma soluo direta para esse problema: abortar as
transaes que realizavam leituras quando houvesse uma
operao de escrita conflitante.
KEMME & ALONSO [6] destacam, tambm, a importncia
de replicar comandos na mesma ordem em que foram
executados no site de origem.
ALMIR et al [1] [2] propem uma tcnica de replicao
sncrona em redes locais LAN e de longa distncia WAN,
consistindo de uma camada responsvel pela comunicao
entre os servidores e outra destinada a efetuar a replicao
propriamente dita. O trabalho em questo contempla, ainda,
um otimizador semntico, cujo objetivo melhorar o
desempenho da replicao.
Do mesmo modo que KEMME & ALONSO[6], ALMIR et
al [1] [2] ressaltam a importncia de se manter, ao replicar, a
ordem em que as atualizaes so realizadas no site de
origem.
GRAY et al [5] comentam os principais problemas
enfrentados durante a replicao de dados sncrona e
assncrona,
comparando-as
e
demonstrando
sua
complexidade, alm de avaliar propostas para a soluo dos
problemas encontrados durante a replicao, discutindo seus
riscos.
O MySQL [7] [8], um dos SGBD selecionados neste
trabalho para ilustrar a aplicao da abordagem prtica que
est sendo sugerida, possui esquema nativo de replicao, que
pode ser utilizado tanto na replicao sncrona quanto
assncrona. Esse recurso, contudo, no permite realizar a
replicao entre bancos de dados heterogneos.
III. ARQUITETURA PROPOSTA
Pretende-se apresentar, nesta seo, um cenrio em que a
natureza distribuda de uma aplicao de bancos de dados
torna o uso de bancos de dados distribudos com replicao
assncrona uma opo indicada de implementao.
Quando se pretende avaliar a real possibilidade de migrar
um sistema de banco de dados centralizado para BDD com
replicao assncrona, necessrio considerar, alm dos
aspectos tcnicos envolvidos na soluo, se as regras de
negcio da aplicao so favorveis migrao. importante

Banco de Dados
observar se os pontos de acesso a dados realizam apenas
consultas ou se realizam consultas e atualizaes, se as
operaes poderiam ser realizadas off-line e sincronizadas
posteriormente e se esse procedimento provocaria excessivas
situaes de conflito.
Deve-se avaliar, tambm, a necessidade de autonomia de
acesso aos dados para os bancos que estariam envolvidos na
soluo, qual a quantidade de transaes presentes nas
operaes de atualizao e se essas transaes envolveriam
mais de um fragmento de dados.
Outro aspecto importante o custo de implementao do
ambiente BDD com replicao assncrona, se comparado a
uma soluo centralizada. Em algumas propostas de
implementao de BDD, os custos envolvidos com aquisio
de SGBD e softwares de controle de replicao podem ser
determinantes para a rejeio da proposta.
Aplicaes que dependem de grande desempenho,
autonomia, flexibilidade e escalabilidade, que so executadas
em computadores pessoais e que apresentam algum grau
independncia de acesso a dados so grandes candidatas ao
uso de BDD com replicao assncrona.
A fim de ilustrar o processo de definio e escolha das
tcnicas de BDD para uma aplicao, considere o cenrio da
Figura 1. Essa uma aplicao projetada com base na
arquitetura de trs camadas, com uso de banco de dados
centralizado e com estaes clientes que possuem apenas um
navegador (browser) e que no dispem de bancos de dados
locais, servidores de aplicao ou regras de negcio.
Considere a necessidade de maior desempenho nas operaes
de consulta e atualizao realizadas nas estaes clientes, a
disperso geogrfica entre as mquinas e uma estreita relao
entre a localizao geogrfica das estaes e os dados
acessados por elas. Nesse cenrio, na maioria das vezes, os
dados so de interesse particular de cada estao cliente.
Porm, eventualmente, alguma estao poderia consultar ou
atualizar um dado de interesse comum a outras estaes.
Considere, ainda, que algumas operaes so implementadas
por transaes. A Figura 1 mostra tambm a heterogeneidade
de tecnologia de interligao utilizada nessa aplicao, que
tira proveito da Internet.
.

Cons ultas /
atuali zaes
SGBD
propriet rio

Conexo dedicada
512 K

Dial 56K

Navegador

Servidor
de
Apli cao

Satlite 128K

Navegador

Figura 1. Aplicao trs camadas com banco de dados centralizado.

54

IV Congresso Brasileiro de Computao CBComp 2004

Duas caractersticas citadas no cenrio anterior devem ser
destacadas:
a) necessidade de maior desempenho;
b) dados de interesse particular de cada estao cliente.
Essas caractersticas apontam, segundo VALDURIEZ [9],
para o uso de fragmentao com replicao, a fim de
introduzir melhoria de desempenho e garantir maior
disponibilidade dos dados.
Segundo BURETTA [4], a seguintes tarefas esto
envolvidas na definio de uma arquitetura de BDD que
utiliza replicao de dados: anlise, projeto, implementao,
administrao e monitoramento. Portanto, preciso optar por
um modelo de replicao, escolher adequadamente os
softwares responsveis pelo controle da distribuio e
gerncia dos dados nos sites envolvidos, determinar como ser
realizada a alocao de dados, se a semntica transacional das
operaes ser mantida, qual o atraso na propagao das
atualizaes e sua granularidade.
Determinado o uso de replicao de dados, preciso
escolher entre replicao parcial ou total, conforme
classificao apresentada por VALDURIEZ [9]. O referido
autor classifica as alternativas para alocao de dados entre
BDD no replicados, totalmente replicados e parcialmente
replicados. Quando se opta por bases de dados no replicadas,
os dados so distribudos em fragmentos entre os sites
envolvidos e em toda a rede s existe uma cpia de cada um
dos fragmentos. Em bases totalmente replicadas, todos os sites
contm todos os dados. Por fim, no modelo de replicao
parcial, cada fragmento de dados est presente em um ou mais
sites.
Segundo VALDURIEZ [9], existem duas estratgias
principais para realizar a fragmentao de dados: horizontal e
vertical. Ainda possvel optar por fragmentao hbrida, na
qual os fragmentos so obtidos pelo uso dessas duas
estratgias em conjunto. A fragmentao horizontal provoca a
diviso das tuplas de uma relao em subconjuntos, enquanto
a fragmentao vertical produz um conjunto de relaes
distintas a partir de uma mesma relao.
Considerando, no cenrio exposto, a relao entre os dados
acessados por cada estao cliente e sua localizao
geogrfica, a replicao parcial a mais adequada.
A respeito do atraso na propagao das atualizaes,
necessrio escolher, segundo a classificao de BURETTA
[4], entre replicao sncrona e assncrona. A Figura 1 mostra
que no h um padro de conexo entre as estaes clientes e
o servidor central. Ao contrrio, as mquinas esto conectadas
ao servidor via Internet, atravs de conexes diversas: dial-up,
satlite, eventualmente por ADSL, Frame Relay, etc. Quando
as regras de negcio da aplicao permitem o uso de
replicao assncrona, possvel diminuir o custo proveniente
de conexes no dedicadas, pois os sites podem conectar-se
apenas no momento da replicao. Outra vantagem garantir
maior autonomia em relao localizao dos dados.
Considerar-se-, para o cenrio em questo, o uso de
replicao assncrona.

Banco de Dados
Dada a escolha do modelo de replicao assncrona, devese considerar a possibilidade de conflitos e a dificuldade de
manuteno da semntica transacional. De acordo com o
cenrio descrito nesta seo, as estaes clientes, futuros sites
no modelo de BDD, podem realizar atualizaes nos dados.
Segundo BURETTA [4], as propriedades ACID de uma
transao no so garantidas quando se implementa replicao
assncrona com possibilidade de atualizaes em qualquer
site. De fato, quando considerado o aspecto global do sistema,
podem ocorrer conflitos que ferem as propriedades ACID.
Portanto, a semntica transacional de uma operao s pode
ser mantida quando considerada sua execuo local. No
momento de sua propagao, os conflitos devem ser
detectados e tratados a nvel global.
Segundo KEMME & ALONSO [6], freqente deixar a
cargo da aplicao usuria a tarefa de manter a consistncia,
procedimento adotado no cenrio em questo.
BURETTA [4] apresenta opes de atualizaes
completas, incrementais ou por propagao delta de eventos
para a implementao da replicao assncrona. No cenrio da
Figura 1, mencionou-se que algumas operaes so
implementadas por transaes. Desta forma, a opo mais
adequada seria a propagao delta de eventos, pois, segundo a
referida autora, essa a estratgia de replicao capaz de
preservar as fronteiras de uma transao ou conjunto de
transaes.
No modelo de BDD, cada estao cliente presente no
modelo de trs camadas descrito em nosso cenrio, seria,
resumidamente, um site com software local e um banco de
dados com suporte ao processamento de transaes. Percebese aqui a necessidade de se determinar qual SGBD seria
utilizado para gerenciar os bancos presentes em cada site.
Diz-se que feita replicao entre bancos de dados
homogneos quando todos os sites participantes possuem o
mesmo SGBD. Porm, com o intuito de no deixar a aplicao
dependente de um nico fornecedor, trabalhar com mais de
uma opo de suporte, ganhar em flexibilidade e
portabilidade, algumas implementaes lidam com replicao
entre bancos de dados heterogneos, em que os SGBD so
diferentes entre os sites.
No cenrio proposto, optar-se- pelo uso de replicao
entre bancos de dados heterogneos. Note que, no exemplo, o
servidor central usa SGBD proprietrio. Destacou-se, no
incio dessa seo, o risco de que os custos envolvidos com
aquisio de SGBD e softwares de controle de replicao
proprietrios inviabilizassem o uso de BDD. Uma opo
vivel para no enfrentar problemas relacionados ao custo,
seria, no cenrio apresentado, manter o SGBD proprietrio j
existente no servidor central e utilizar um SGBD gratuito entre
os demais sites.
Optou-se, ainda, por replicao procedural, propagando-se
os procedimentos a serem executados no lugar de propagar
dados.
De forma resumida, a arquitetura de BDD seria
implementada, nesse exemplo, a partir de replicao parcial,
assncrona, com propagao delta de eventos, procedural,
55

IV Congresso Brasileiro de Computao CBComp 2004

entre bancos de dados heterogneos. Destaca-se ainda, a
utilizao de SGBD livres e comerciais na soluo proposta.
A. O problema versus a proposta
Se considerarmos o uso de replicao assncrona entre
bancos de dados heterogneos, conforme definido na soluo
de BDD para o cenrio da Figura 1, ser necessrio utilizar
um gateway que possibilite a comunicao entre os SGBD ou
um software de replicao entre bancos heterogneos. Propese aqui a escolha de uma combinao apropriada de tcnicas
para replicao, a fim de eliminar a necessidade de um
gateway ou de alguma ferramenta, nativa ou de terceiros,
quando se opta pelo uso de replicao assncrona entre bancos
de dados heterogneos.
Omitiu-se, na seo III, a discusso sobre qual dos modelos
apresentados por BURETTA [4] para manter a definio do
detentor do direito de propriedade e a consistncia de dados
seria escolhido: mestre/escravo ou atualizvel em qualquer
lugar. A ausncia desse aspecto da implementao de BDD
naquela seo foi proposital, pois faz parte da soluo
proposta neste trabalho.
preciso recordar que, no cenrio da Figura 1, todos os
sites devem poder realizar alteraes de dados. Inicialmente,
esta seria uma caracterstica indicativa do uso do modelo
atualizvel em qualquer lugar. Porm, como no ser utilizado
um gateway ou software especfico para a replicao de dados
entre bancos heterogneos, prope-se aqui um controle
centralizado das replicaes, ainda que se permitam
atualizaes realizadas em qualquer site. Seria como se
pudssemos utilizar o modelo mestre/escravo em conjunto
com o modelo atualizvel em qualquer lugar.
Nessa proposta, o mestre no seria o nico site onde seria
possvel realizar atualizaes. Na verdade, seria possvel
efetuar modificaes no site mestre, da mesma maneira que
em qualquer outro. Porm, ele seria o responsvel por
controlar as replicaes e tambm o nico detentor de rplicas
de todos os fragmentos envolvidos. Essa abordagem usual
em bancos de dados sincronizados intermitentemente e em
certas solues comerciais de replicao, tais como
updateable snapshots, presentes na soluo de replicao
avanada fornecida pela empresa Oracle Inc. Na prxima
subseo sero apresentados os detalhes de implementao
dessa proposta.
B. A implementao
Para facilitar a compreenso do que se est propondo, sero
apresentados, inicialmente, os componentes que atuam no
mestre e nos demais sites. Posteriormente, mostrar-se- como
esses componentes trabalham em conjunto.
AGENDA: tabela que armazena a relao entre as
transaes presentes na fila de transaes do mestre e os sites
nos quais elas devem ser aplicadas. Indica quais sites devem
receber quais transaes.
ATUALIZA
MESTRE:
conjunto
de
triggers
implementados na tabela fila de transaes localizada no
mestre. Responsvel por aplicar, no mestre, as transaes
efetuadas nos demais sites.

Banco de Dados
BANCO DE DADOS LOCAL: banco de dados onde so
armazenados os dados do negcio. Pode haver um ou mais em
cada site presente na aplicao.
CAPTURA: componente responsvel por capturar as
transaes provenientes da aplicao, aplicar no banco local e,
caso seja uma operao que deve ser replicada, armazenar na
fila de transaes mantendo a ordem original de sua execuo.
CATLOGO DE REPLICAO: banco de dados,
presente apenas no servidor mestre, que contm os dados
sobre a replicao. Armazena quais so os sites envolvidos,
quais as rplicas presentes em cada um dos sites, o histrico
de falhas e sucessos durante a distribuio de dados, qual o
atraso de propagao configurado para cada site, quais aes
devem ser tomadas em caso de falha, etc.
ESCALONA PROPAGAES: componente responsvel
por popular a tabela denominada agenda. A partir de consultas
ao catlogo de replicao, com o conhecimento da distribuio
das rplicas dos fragmentos pelos sites e a partir do uso de
triggers, grava na agenda a indicao dos sites que devem
receber as transaes no momento em que se conectarem para
sincronizar os dados.
EXECUTA SNAPSHOT: componente executado quando
um site escravo no 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 sincronizao em momento indevido; utilizado,
tambm, no momento em que um novo site escravo ingressa
no esquema de replicao, promovendo a primeira carga de
dados desse novo site.
FILA DE TRANSAES - FT: tabela que armazena as
transaes que sero replicadas para outros sites.
FILA DE TRANSAES REPLICADAS - FTR: tabela
que armazena as transaes originadas de outros sites e que
devero ser aplicadas localmente.
PROPAGA: componente responsvel por transferir o
contedo da FT do site onde o dado foi atualizado para a FTR
dos sites escravos que recebero a sua rplica. Tambm
transfere o contedo da FT dos sites escravos para a FT do
site mestre.
Os componentes e as tabelas de dados apresentadas
anteriormente esto organizados, no processo de replicao de
dados, conforme a Figura 2.
SIT EMEST RE

SIT E ESCRAVO

PROPAGA

APLICA O

TRANSAES

CAPTURA

FILA DE
TRANSAES
REPLICADAS - FTR

ESCALONA
PROPAGA ES

AGENDA

CATLOGO DE
REPLICAO

FILA DE
TRANSAES - FT
FILA DE
TRANSAES - FT

ATUALIZA
MESTRE

PROPAGA
BANCO DE DADOS
LOCAL - Livre
EXE CUTA
SNAPSHOT

BANCO DE DADOS
LOCAL - Proprietrio

Figura 2. Implementao de replicao assncrona entre bancos heterogneos.

56

IV Congresso Brasileiro de Computao CBComp 2004

O processo de replicao desse modelo pode ser
exemplificado com os passos descritos a seguir.
1 Passo. O componente CAPTURA recebe, da aplicao,
as transaes que devem ser executadas no banco local. Alm
de executar essas transaes, o componente grava aquelas que
envolvem operaes de insero, remoo e atualizao de
dados, na tabela FILA DE TRANSAES.
2 Passo. No instante determinado para que os dados sejam
sincronizados, o componente PROPAGA, situado no site
escravo, captura as transaes previamente gravadas na FILA
DE TRANSAES local, se conecta e as grava, no mestre, na
FILA DE TRANSAES daquele site.
3 Passo. Assim que uma transao gravada na FILA DE
TRANSAES do mestre, os triggers que compem o
componente ATUALIZA MESTRE executam essa transao,
garantindo que a rplica presente no banco mestre fique
atualizada.
4 Passo. Aps uma transao ser gravada na FILA DE
TRANSAES do mestre, com aes disparadas por triggers,
o componente ESCALONA PROPAGAES consulta o
catlogo de replicao e identifica para quais sites escravos a
transao deve ser replicada. Aps a consulta ao catlogo,
esse componente grava, na AGENDA, para cada site escravo
que contm uma rplica do fragmento alterado, uma relao
entre esse site e a transao presente na FILA DE
TRANSAES.
5 Passo. Aps a execuo do passo 2, enquanto os passos
3 e 4 so executados, o componente PROPAGA verifica na
AGENDA do mestre se existem transaes que devam ser
propagadas para o site escravo conectado. Caso existam, esse
componente efetua sua captura, grava na tabela FILA DE
TRANSAES REPLICADAS do escravo e exclui da
AGENDA do mestre as referncias s transaes j copiadas
para aquele escravo. Alm de efetuar essa excluso, o
componente PROPAGA verifica se existe algum outro
registro na agenda da transao que acabou de copiar,
relacionado a algum outro site. A eventual inexistncia desse
registro significa que todos os sites escravos j capturaram
aquela transao. Nesse caso, a transao excluda da FILA
DE TRANSAES do mestre. Copiadas as transaes que se
referem ao site escravo conectado, esse site se desconecta do
mestre.
6 Passo. Aps se desconectar do mestre, o escravo
processa cada uma das transaes presentes em sua tabela
local FILA DE TRANSAES REPLICADAS.
Os seis passos descritos anteriormente constituem a base de
funcionamento da proposta deste trabalho. Uma exceo pode
ocorrer quando um site escravo deixa de sincronizar os dados
por um tempo superior ao limite configurado. Nesse caso, no
passo 2, logo aps se conectar ao mestre, ao invs de gravar
na fila de transaes daquele site as transaes a replicar, o
componente EXECUTA SNAPSHOT instanciado. Esse
componente retorna para o componente CAPTURA uma lista
de operaes que deixam o site escravo atualizado. Aps uma
sincronizao que envolve snapshot, o site escravo se
desconecta do servidor sem passar pelos passos trs, quatro,

Banco de Dados
cinco e seis. Na prxima vez em que este mesmo site iniciar
um processo de sincronizao, desde que dentro do prazo
configurado para que ocorra a replicao, todos os passos
sero executados.
IV. RESULTADOS
Este artigo no apresenta medidas de desempenho da
soluo implementada. Contudo, foi possvel acompanhar
empiricamente o comportamento de uma aplicao comercial
que emprega a arquitetura proposta, utilizada em uma empresa
cuja identidade no ser revelada, a pedido da mesma.
O cenrio da empresa em questo era muito parecido com o
da Figura 1: banco de dados central, estaes clientes que
acessavam a aplicao com o uso de um navegador (browser)
e se conectavam ao servidor por intermdio da Internet.
As estaes clientes da referida empresa estavam
localizadas em cidades do Rio Grande do Sul, So Paulo,
Minas Gerais e Rio de Janeiro. Havia 47 estaes conectadas
a um servidor localizado em So Paulo. Havia variaes entre
as configuraes de hardware das estaes, mas em geral, os
computadores eram compostos de processadores Intel Pentium
II, com 128 Megabytes de memria RAM, adaptadores de
modem, rede, som e vdeo off-board. O sistema operacional
dessas estaes era o Windows 98 Segunda Edio. A
conexo com a Internet dependia da tecnologia encontrada em
cada um dos locais onde as mquinas estavam instaladas. A
grande maioria delas se conectava a partir de conexo dial-up,
mas algumas se valiam de conexo ADSL.
O servidor central de banco de dados da empresa em exame
estava localizado em So Paulo, ligado Internet via conexo
dedicada, com taxa de transferncia de 512 Kbps (quilobits
por segundo). O SGBD utilizado nesse servidor era o
SQLServer 2000.
Estudou-se detalhadamente a aplicao da empresa sub
examine, a fim de avaliar se o uso de replicao assncrona
seria realmente indicado. As condies do negcio da empresa
favoreciam o teste. Ademais,
a direo da referida
organizao determinou sua equipe de engenheiros de
software que buscasse uma nova tcnica que garantisse maior
desempenho, disponibilidade e diminusse os custos
relacionados s conexes discadas. Por conseguinte, optou-se
por migrar o banco de dados centralizado para um banco
distribudo, com o uso de replicao assncrona, desde que
fossem garantidos a diminuio de custos, a melhoria do
desempenho e um rpido retorno ao sistema centralizado, caso
a migrao no fosse bem sucedida.
Optou-se pelo uso de MySQL nos sites escravos e
manteve-se o SQLServer 2000 no site mestre.
Implementado o ambiente descrito na Seo III,
acompanhou-se o desempenho dos sites escravos e do
servidor, observando-se que os primeiros se comportaram bem
no que diz respeito ao desempenho e autonomia adquirida
com o modelo implementado.
O principal problema observado nos sites escravos dizia
respeito conexo. Freqentemente a conexo era
interrompida enquanto estava ocorrendo o processo de
57

IV Congresso Brasileiro de Computao CBComp 2004

replicao. Esse problema diminuiu com a padronizao do
modem empregado e substituio do provedor de acesso
Internet, selecionando-se uma empresa que oferecia grande
capilaridade e conexo de qualidade. Tecnicamente, a
interrupo da conexo no inviabilizava a replicao, pois o
componente PROPAGA, descrito na subseo III.B, s
exclua uma linha da tabela AGENDA ou da FILA DE
TRANSAES aps garantir que a transao era gravada na
FT ou na FTR de destino.
Detectou-se um problema de desempenho no site mestre,
no momento em que o componente PROPAGA era executado.
Esse problema era causado pela grande quantidade de
registros presentes nas tabelas AGENDA e FILA DE
TRANSAES. O processo de encontrar as ocorrncias na
agenda que se referiam a um determinado site e buscar as
respectivas transaes na FT envolvia alto custo de
processamento.
Para solucionar o problema de desempenho do componente
PROPAGA, uma variao do modelo proposto foi
implementada: em lugar de utilizar-se apenas uma tabela FT e
uma tabela AGENDA no site mestre, criou-se uma tabela
AGENDA (e uma FT correspondente) para cada tabela do
banco de dados local do site mestre que continha dados
replicados. Por meio desse expediente, garantiu-se que o
componente PROPAGA fazia acesso a tabelas com menor
volume de registros.
As operaes de snapshot, embora raras, ocorreram com
sucesso absoluto. Quando um site escravo se conectava ao site
mestre para realizar a sincronizao dos dados em um tempo
maior que o configurado e maior do que o tempo de tolerncia
estimado no CATLOGO DE REPLICAO, o snapshot era
realizado sem apresentar problemas. Verificou-se que essa
operao consumia tempo significativo, conforme esperado.
Na sintaxe dos comandos presentes nas transaes
envolvidas na replicao, empregou-se um subconjunto
comum dos dialetos SQL dos SGBD envolvidos. Essa
simplificao no implicou na perda de generalidade da
proposta, pois seria possvel utilizar um analisador sinttico e
tradutor de dialetos SQL.
O grande desafio encontrado na implementao
relacionava-se s situaes de conflito. O negcio da empresa
mencionada no demandava a utilizao de uma aplicao
com excessivas operaes conflitantes. Porm, os conflitos
ocorriam, eventualmente, e precisavam ser tratados. Um
esquema de deteco de conflitos, no entanto, no faz parte,
por ora, da proposta desse trabalho. Na verdade, o fato de a
abordagem sugerida envolver replicao procedural sugere
que a deteco e tratamento de conflitos sejam efetuados na
prpria aplicao, e no pelo mecanismo de replicao. Essa
a maneira como a replicao procedural implementada pelos
principais fornecedores de SGBD comerciais (Oracle, e.g.).
Desta forma, os programadores da empresa em tela inseriram
na aplicao um mdulo com essa finalidade.
A empresa referenciada nesta Seo vem utilizando a
tcnica de replicao assncrona entre bancos de dados
heterogneos proposta neste trabalho h trs meses. Os

Banco de Dados
resultados apresentados tm sido satisfatrios, principalmente
em relao queda nos custos de telecomunicaes, tendo em
vista que, anteriormente, as estaes clientes eram mantidas
conectadas durante todo o tempo. Ademais, a execuo da
aplicao no cliente resultou em desempenho superior
aplicao centralizada.
V. CONCLUSO
Neste trabalho apresentou-se uma proposta para
implementao de replicao assncrona entre bancos de
dados heterogneos. Foram comentados alguns dos trabalhos
relacionados ao tema, os quais foram comparados
abordagem que se pretendia defender.
No foram exibidos resultados experimentais tangveis,
contendo medidas obtidas a partir de experimentos efetuados
em ambiente controlado. Contudo, foi discutido um exemplo
real de implementao da proposta, que permite afirmar, a
partir dos resultados obtidos, que a proposta vivel, do ponto
de vista funcional e quanto ao desempenho. Mais que isso,
possvel dizer que a abordagem sugerida
garante
expansibilidade, portabilidade, baixo custo e ainda possibilita
o uso conjunto de sistemas de gerncia de banco de dados
livres e proprietrios, sem a necessidade do uso de gateways
ou features que viabilizem essa operao.
Algumas possveis linhas de investigao futura seriam: a)
realizao de experimentos com variveis controladas, a fim
de mensurar o desempenho e a expansibilidade da replicao,
quando implementada conforme sugesto contida neste
trabalho; b) utilizao de replicao de dados em lugar da
replicao procedural, o que permitiria a incluso de recursos
para deteco e tratamento de conflitos na soluo proposta;
c) incorporao de um tradutor de dialetos SQL na arquitetura
de replicao sugerida neste artigo.
VI. REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]

ALMIR, Y., DANILOV C., MISKIN-AMIR. M, STANTON J. On the

Performance of Wide-Area Synchronous Database Replication, CNDS Johns Hopkins University, 2002
ALMIR, Y., DANILOV C., MISKIN-AMIR. M, STANTON J., TUTU
C. Practical Wide-Area Database Replication, CNDS - Jonhs Hopkins
University, 2002
BERNSTEIN P.A.; HADZILACOS V.;GOODMAN, N. Concurrency
Control and Recovery in Database Systems. Massachusetts: Addison
Wesley, 1987.
BURETTA, M. Data Replication: tools and techniques for managing
distributed information. Estados Unidos da Amrica: John Wiley e Sons,
Inc, 1997. 360p.
GRAY, J., HELLAND, P., ONEIL, P., SHASHA, D. The Dangers of
Replication and a Solution, ACM SIGMOD, Montreal, Quebec, Canad,
1996
KEMME B.; ALONSO G. Dont be lazy, be consistent: Postgres-R, a
new way to implement Database Replication, VLDB, Cairo, Egypt, 2000
MySQL

Replication
in
MySQL
http://www.mysql.com/doc/en/Replication.html
MySQL
Transactions
Overview
http://www.informit.com/isapi/product_id~%7B056A857F-D4E54FAD-9AB5-1E97E2DD1C72%7D/content/index.asp
VALDURIEZ P.; ZSU M. Principles of Distributed Database Systems.
Nova Jersey: Prentice-Hall, 1999. 666p.

58