Palestra no Firebird Developers Day

Estaremos realizando uma palestra na oitava edição do Firebird Developers Day a ser realizada no dia 23 de julho de 2011 (sábado) em Piracicaba-SP. Nesta palestra mostraremos como fazer para transformar uma aplicação feita originalmente para trabalhar de forma centralizada em uma única base de dados em uma aplicação que pode trabalhar com N bases de dados distribuídas geograficamente nos diversos sites da empresa (matriz e filiais, pontos de atendimento, franquias, etc)

Porque usar replicação de banco de dados e não de storage

Apesar da replicação de storage ser mais simples de instalar e administrar, ao compararmos com a replicação de banco de dados temos um “overhead” enorme no consumo de banda de rede podendo chegar a quase 10 vezes mais volume de dados trafegado na rede. A cada operação de insert, update ou delete em um banco de dados, à nível de disco o SGBD grava inúmeras páginas de dados, tais como a página da linha / coluna da tabela alterada propriamente dita, mais páginas de índices, páginas de logs, etc, e assim um replicador de disco / storage terá que replicar para o servidor remoto todas estas páginas alteradas, ao longo que em um replicador de banco de dados como o OBJECTMMRS o único dado trafegado é o dado realmente alterado. É por isso que em projetos de replicação de disco / storage há a necessidade de grande banda de rede em contrapartida com projetos de replicação de banco de dados onde o consumo de banda de rede é mínimo.

Uma outra diferença muito importante é que no caso da replicação de disco / storage, a base de dados remota não pode ser usada, ela fica offline, não podendo ser usada nem para consultas.

Esta informação foi extraída do artigo escrito pelo experiente DBA Oracle Tom Kyte, podendo ser lida em http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:3586678100346900805

Qualquer sistema já desenvolvido pode usar replicação assíncrona ?

A resposta não é apenas um sim ou um não, é um depende.

As maiores restrições para o uso de um replicador assíncrono de dados são:

  1. Sua base de dados precisa estar com pelo menos chaves primárias formalmente definidas, e o ideal é que também as chaves estrangeiras estejam formalmente definidas.
  2. A forma de usar identificadores únicos precisa ser ajustada. Por exemplo se sua aplicação usa sequences (ou colunas tipo identifier, etc) para a atribuição automática de um número para um cliente, um pedido de vendas, etc, será necessário trabalhar no sentido de criar-se um script para o ajuste das sequências em cada servidor de banco de dados que for existir. . Numa situação onde tivessemos 3 servidores, por exemplo, num dos servidores a sequence numeraria na ordem 1, 4, 7, etc, no outro servidor seria 2, 5, 8, etc e no terceiro seria 3, 6, 9, etc.
  3. Um outro cuidado refere-se ao uso de triggers pela aplicação. Se a aplicação não usa triggers ou a usa apenas para atribuição de IDs, etc, então não tem nenhum problema. Se a aplicação usa triggers então estas triggers precisam ser analisadas, principalmente triggers que façam totalizações, resumos, etc. Exemplificando: Se temos uma trigger num sistema contábil que automaticamente ajusta o saldo de uma conta a partir de um lançamento contábil, então temos que desabilitar esta trigger nos servidores deixando-a ativa apenas em um dos servidores para que não haja concorrência na atualização deste saldo gerando inconsistências. Ficando ativa em apenas um dos servidores ela calculará o saldo corretamente à medida que receba os lançamentos provenientes da replicação dos outros servidores, e depois replica o saldo atualizado para todos.
  4. Um último cuidado, um pouco relacionado ao item anterior, é quanto à concorrência. Se sua aplicação por exemplo é de controle de estoque, então temos que controlar a aplicação para que um servidor admita transações de estoque apenas relativa à sua filial / site caso contrário teremos saldos de estoque inconsistentes. Se você tem então uma tabela ESTOQUE que contenha o código do produto e o código do local, então o servidor local pode atualizar ESTOQUE apenas para o código do local onde está, se atualizar o saldo de itens de outros servidores isso vai gerar erros nos saldos devido à falta de sincronismo instantâneo entre os servidores. (replicador assíncrono não tem two-phase-commit).

As restrições acima não são exclusivas do replicador ObjectMMRS, é muito importante entender que estas limitações são para QUALQUER replicador assíncrono, não existe meios de se livrar destas limitações sem trabalhar de forma síncrona.

Versões gratuitas dos SGBDS comerciais

A maioria dos grandes fabricantes de bancos de dados disponibilizou gratuitamente versões limitadas apenas na capacidade de armazenamento de seus gerenciadores de bancos de dados.

Embora funcione quase que 100% igual às versões comerciais, a maioria deles não disponibiliza os recursos mais avançados de banco como replicação.

Usando o replicador de base de dados da OBJECT Sistemas, você poderá utilizar estas bases de dados free e mesmo assim usar replicação multi-master / bi-direcional de dados com um custo bastante reduzido.

Entre em contato conosco que ajudamos a elaborar um projeto de menor custo/benefício para a sua aplicação descentralizada usando bancos de dados free (também chamados versões Express).

O replicador foi testado e homologado para funcionar com as seguintes bases Express:

  • DB2 Express
  • Oracle XE
  • SQLServer  2005 Express

Modelo de dados destino não precisa ser idêntico ao de origem

O ObjectMMRS trabalha também como se fosse uma ferramenta ETL (Extract, Transform and Load), a diferênça é que o “Extract” e o “Load” são feitos de forma contínua, tão rápido quanto a sua plataforma suporte (temos casos de ciclos de replicação, ou seja, ciclos de extract e load com intervalos de 5 segundos).

O “Transform” pode ser feito de 2 formas. Existe uma forma simples onde pode-se apenas mapear nomes de colunas e tabelas de origem com nomes de colunas e tabelas destino, e também existe a possibilidade de desenvolver uma classe java que implemente uma Interface pré-definida e com isso pode-se explorar toda a potencialidade da linguagem java para fazer qualquer transformação de dados necessária, inclusive fazendo acessos a bases de dados, sistema de arquivos, etc.

Portanto o ObjectMMRS não se limita a apenas replicar dados, ele também trabalha como um “integrador”, fazendo qualquer transformação necessária para a integração de sistemas heterogêneos em tempo real.

Replicação de base de dados com o ObjectMMRS

O ObjectMMRS é nossa suite de softwares para projetos de replicação de banco de dados.

Criado em 2002, o software foi evoluindo até tornar-se uma verdadeira ferramenta multi-uso quando o assunto é replicar dados em tempo real de forma bidirecional entre servidores remotos, sejam eles usando um mesmo software de banco de dados ou mesmo gerenciadores de diferentes fabricantes.

O produto tem tecnologia nacional, é perfeitamente adaptado às piores condições possíveis de internet, possibilitando assim a troca eficiente de dados mesmo em instáveis e restritas bandas de rede (32Kb via satélite, etc).

Assista a um vídeo mostrando a replicação de cerca de 50 mil operações entre bancos de dados postgresql, oracle e sqlserver em ambiente Mac OS e Windows.

Ficha técnica do produto

Clique aqui para solicitar um orçamento

Arquitetura do Software ObjectMMRS

Metáfora

A arquitetura é baseada na metáfora Editor (Publisher), Publicação (Publish), Assinantes (Subscriber) e Assinaturas (Subscription).
As bases de dados “master”, ou seja, as bases onde os dados sofrem modificações que devem ser replicadas, são os Editores (Publisher).
As bases de dados que recebem dados (slaves), independente se atuam ou não também como “master”, chamamos de Assinantes (Subscriber).
As tabelas da base “master” que são replicadas damos o nome de publicações (Publish), e a matriz entre publicações e assinantes damos o nome de Assinaturas (Subscription), sendo as assinaturas o relacionamento entre as publicações (tabelas) e os seus assinantes (servidores slave).

Funcionamento

O ObjectMMRS é um replicador assíncrono e bi-direcional de bases de dados, ou também chamado multi-master lazy.
É um software que prima pela simplicidade, não utiliza recursos específicos (de baixo nível ou não oficialmente documentados) de determinado SGBD, como leitura de logs de transações, etc – funciona através da coleta de informações através de uma trigger que é gerada para cada tabela a ser replicada. Esta trigger coleta informações a nível de coluna e linha alterada de forma que o replicador possa replicar única e exclusivamente dados realmente alterados e não a linha completa, reduzindo assim problemas de consumo excessivo de rede e também minimizando problemas de concorrência na atualização dos dados.
Esta trigger é gerada pelo replicador e pode até mesmo ser editada e alterada pelo cliente caso queira implementar alguma particularidade.
As informações coletadas pela trigger são armazenadas em tabelas que chamamos de “filas de operações a replicar”, e um engine (processo) consome esta fila a cada N segundos (configurável) enviando dados de forma gerenciada para os servidores apropriados, de acordo com a configuração realizada.
Em ocorrências de queda de rede, indisponibilidade do servidor remoto, etc, esta fila de operações a replicar é mantida, e a operação tem garantia de entrega assim que a rede ou o servidor remoto for restabelecido. Após um número X de tentativas, configurável, o engine pode opcionalmente enviar emails de alertas aos DBAs responsáveis para que verifiquem o problema com rede e/ou servidores.
O processamento da replicação é totalmente assíncrono e ocorre em “background”, com baixo overhead nos servidores de banco de dados.

Flexibilidade de instalação

O software ObjectMMRS pode ser instalado de N formas distintas, atendendo a várias necessidades específicas de cada projeto. Estaremos ilustrando a seguir algumas formas comuns de instalação.

Primeiro caso: Replicação unidirecional envolvendo 2 servidores – 1 master e 1 slave

Este é o caso mais simples onde o ObjectMMRS pode ser usado, e neste tipo de instalação temos a seguinte configuração padrão:
Servidor Master
Software de banco de dados
Software replicador
Dicionário de dados do replicador
Servidor Slave
Software de banco de dados
(Não necessita instalar nenhum software replicador e nem dicionário de dados)

Uma forma alternativa, em casos onde o servidor master esteja muito sobrecarregado:
Servidor Master
Software de banco de dados
Dicionário de dados do replicador
Servidor de Replicação
Software replicador
Banco de dados embedded do replicador (fila de operações a replicar)
Servidor Slave
Software de banco de dados
(Não necessita instalar nenhum software replicador e nem dicionário de dados)

Segundo caso: Replicação unidirecional envolvendo 1 master e N slaves, com N relativamente pequeno (menos de 30 por exemplo).

Servidor Master
Software de banco de dados
Software replicador
Dicionário de dados do replicador
N Servidores Slave
Software de banco de dados
(Não necessita instalar nenhum software replicador e nem dicionário de dados)

Uma forma alternativa, em casos onde o servidor master esteja muito sobrecarregado:
Servidor Master
Software de banco de dados
Dicionário de dados do replicador
Servidor de Replicação
Software replicador
Banco de dados embedded do replicador (fila de operações a replicar)
(10 threads simultâneas)
N Servidores Slave
Software de banco de dados
(Não necessita instalar nenhum software replicador e nem dicionário de dados)

Terceiro caso: Replicação unidirecional envolvendo 1 master e N slaves, com N relativamente grande (mais de 30 por exemplo).

Servidor Master
Software de banco de dados
Dicionário de dados do replicador

Servidores de Replicação (1 a cada 30 slaves)
Software replicador
Banco de dados embedded do replicador (fila de operações a replicar)
(Cada servidor de replicação rodando 1 engine com 10 threads simultâneas)
N Servidores Slave
Software de banco de dados
(Não necessita instalar nenhum software replicador e nem dicionário de dados)

OBS.: No caso de replicação bi-direcional a diferença é que teremos software replicador instalado em todos os servidores e não apenas no “master” central.

Flexibilidade de Uso

O ObjectMMRS permite total integração com softwares desenvolvidos pelo cliente, permitindo ao cliente consultar status, logs de operações a replicar, etc, diretamente no dicionário de dados do replicador, que é fornecido completamente documentado de forma a facilitar o desenvolvimento pelo cliente de qualquer interface customizada para administrar e monitorar os engines de replicação.
O engine possui “scheduler” próprio configurável para disparar ciclos de replicação a cada N segundos, este engine também pode ser configurado para disparar ciclos de replicação comandados pela aplicação do cliente.
O ObjectMMRS disponibiliza uma interface Java para que o cliente possa desenvolver classes Java que implementem esta interface e com isso podem ter total controle da replicação, podendo por exemplo desenvolver integrações com webservices, mainframes, etc.

Independente de Plataforma

O ObjectMMRS é um software 100% Java, podendo ser utilizado em qualquer ambiente operacional onde Java 5 possa ser executado. E em casos de servidores exclusivamente atuando como “slave” nenhum software é necessário, portanto basta ao servidor “slave” ser um banco de dados relacional acessível através de drivers padrão JDBC.

Integração de Sistemas

A OBJECT Sistemas ao longo de seus mais de 14 anos no mercado realizou diversos projetos para integração de sistemas.

Realizamos integrações nas mais heterogêneas plataformas, usando todos os tipos de recursos técnicos tais como replicação de banco de dados, customização de softwares ETL, desenvolvimento de servidores customizados em plataforma java ou C/C++/Corba, interfaceamento com mainframes através de sockets, emulação de terminal com varredura de tela, etc.

Realizamos projetos nos ambientes operacionais:

  • Sun Solaris
  • IBM/AIX
  • Unixware
  • FreeBsd
  • Linux (Slackware, Red Hat, Fedora, Mandrake, Debian, Ubuntu, Suse)
  • Windows (NT, 2000, 2003, XP, Vista, 7, etc)
  • Novell
  • Mainframes IBM e Unisys

Temos experiência na construção de servidores para processamento síncrono ou assíncrono de transações, todos com alta robustez e confiabilidade, usamos mecanismos de log que permitem um perfeito monitoramento da operação, inclusive integrando com ferramentas SNMP.

Sigilo e confidencialidade total em todos os nossos projetos.

Desenvolvemos soluções customizadas para atender exatamente às suas necessidades.