P>
Clique aqui para ler todos os artigos desta edição
Projetando sistemas descentralizados usando replicação de dados "multi-master"
por Wagner Corrêa Ramos
Trabalhando na área de sistemas há 19 anos, presenciei em diversas oportunidades o problema de como modelar e manipular dados em empresas com mais de um site físico, algumas vezes com filiais espalhadas por todo o Brasil, ou ainda multinacionais. Até alguns anos atrás, não havia solução economicamente viável para pequenas ou médias empresas, havendo apenas as soluções dos grandes fabricantes de SGBDs, que além do alto custo, exigiam uma infra-estrutura de rede bastante cara e robusta para que funcionassem. Uma solução utilizada era o uso de terminais "burros", onde o usuário acessava o sistema instalado no servidor em uma das empresas (matriz) através de linhas de comunicação dedicadas, lentas e também caras.
Uma das soluções disponíveis atualmente é o uso de sistemas com interface web, que podem ser instalados em um servidor central (matriz) e acessados pelas outras empresas (filiais) através da internet. Considero essa uma solução melhor que as anteriores, principalmente pelo fato de que atualmente podemos encontrar conexões banda larga com preços bastante acessíveis. A interface com o usuário em muitas situações é melhor que a dos terminais "burros". Enfim, é uma solução razoável, mas ainda temos o problema do desempenho e da disponibilidade do sistema. Muitas empresas não pensam em colocar sistemas críticos em arquitetura web. Imagine, por exemplo, a situação onde um cliente esteja no caixa de um supermercado, com pressa de ir embora, querendo pagar sua conta, e tendo que esperar pacientemente a emissão de uma nota fiscal porque o sistema está lento ou porque a internet está fora do ar.
A replicação de dados já foi considerada uma solução para estes problemas, mas geralmente era deixada de lado por exigirem infra-estrutura de alto custo. Hoje, com o surgimento de softwares open source ou proprietários de baixo custo, e com o barateamento da tecnologia empregada na replicação, tornou-se muito mais fácil a solução para o problema apresentado. Depois de anos batendo de frente com este problema, acredito que o quebra-cabeça começa a se resolver de forma simples e eficiente.
Veremos nesse artigo os principais conceitos sobre replicação de dados, discutindo os tipos de replicadores, modelagem e implementação de bancos de dados para trabalhar corretamente com replicação “multi-master”, apresentando também um estudo de caso real.
Replicação de Dados
Replicação é um meio de se copiar (replicar) de forma gerenciada os dados entre servidores, que podem estar próximos ou a centenas de quilômetros de distância. Nos últimos anos houve uma avalanche de lançamentos de produtos para replicação de dados no mercado. Só para o PostgreSQL existem mais de cinco produtos open source (slony-I, eRServer, Postgres-R, DBBalancer, DBMirror, etc) e alguns outros comerciais. Outros bancos, como o Firebird e o MySQL, também possuem produtos com essa função. Podemos dizer que, para a maioria dos SGBDs open source, existe pelo menos uma opção de replicação gratuita e outras de custo bastante reduzidos.
Existem dois grandes grupos de softwares replicadores: os replicadores "lazy" (lentos, preguiçosos) e os replicadores "eager" (ansiosos, impulsivos). Diversos artigos exibem as diversas vantagens dos replicadores "eager" sobre os "lazy", mas todos eles concordam em dizer que o melhor replicador para uma empresa pode não ser o melhor para outra, que a solução ótima para um pode não ser a solução ótima para todos.
A seguir explicarei resumidamente o que é replicador "lazy" e replicador "eager", mencionando suas principais diferenças:
· Replicador lazy: é um mecanismo assíncrono, com transações não atômicas entre servidores, que trabalha normalmente através da replicação de logs. Lentidão de rede não interfere no desempenho dos servidores individualmente. Assim, na replicação "lazy" as atualizações feitas em um banco de dados são primeiro gravadas nas tabelas do próprio banco e em uma tabela de log. Depois, através de um processo assíncrono, o log é lido e as atualizações são propagadas para os outros servidores.
· Replicador eager: é um mecanismo síncrono com transações entre servidores atômicas e controle de transação entre diversos servidores. No caso de lentidão de rede, há um impacto negativo no desempenho de todos os servidores. Assim, na replicação "eager" as atualizações são feitas em todos os servidores em tempo real, havendo inclusive controle transacional, ou seja, se em algum servidor a transação falhar, ela é desfeita em todos os outros servidores.
Agora que sabemos qual a diferença entre os replicadores lazy e eager, fica claro que existe aplicação para ambos os tipos. O mecanismo eager, por exemplo, se encaixa bem em um esquema de transações bancárias, onde precisamos ter uma posição consistente das informações das contas, independente de onde (agência, cidade, estado ou até país) o cliente esteja consultando-as ou realizando saques. É de extrema importância que as alterações sejam refletidas em todos os servidores em um mesmo momento. E para os outros tipos de aplicações? Será mesmo que todos precisam da replicação "eager"?
A resposta não é simples, pois não depende apenas da aplicação em si, mas também de como o modelo do banco de dados foi projetado. Para que uma aplicação possa usar o modelo "lazy", o banco de dados precisa estar modelado de forma a não ter concorrências em transações entre sites diferentes. Como herdamos a cultura de modelar o BD pensando em um modelo único e centralizado, pode se tornar complicado começar, de uma hora para outra, a modelar o banco de dados para ser usado de forma descentralizada. Além disso, a aplicação também precisa ter “conhecimento” desta modelagem.
