Www.FirebirdDevelopersDay.com.br © 2008 – Wagner Corrêa Ramos 1 Bem-vindo ao Firebird Developers Day 2008 “Aumentando a disponibilidade e o desempenho

www.FirebirdDevelopersDay.com.br © 2008 – Wagner Corrêa Ramos1

Bem-vindo ao Firebird Developers Day 2008

“Aumentando a disponibilidade e o desempenho usando replicação de dados”

Wagner Corrêa Ramos

OBJECT Sistemashttp://www.object.com.br


Roteiro da Palestra

• Apresentação• Conceitos de replicação: Síncrono vs. Assíncrono,

Unidirecional vs. Bidirecional, topologias, etc.• Prós e contras do uso de replicação: Aumento de

complexidade vs. benefícios.• Identificando o esquema ideal de replicação para o seu

tipo de aplicação.• Adaptações necessárias no modelo de dados e na

aplicação para usar replicação bidirecional. Projete corretamente hoje, para usar futuramente replicação.

• CASE de sucesso de replicação com o uso do produto ObjectMMRS com FB 2.x

• Espaço aberto para questões


Apresentação

• Wagner Corrêa Ramos– Diretor da OBJECT Sistemas– Desenvolvedor de software desde 1985

• BASIC, COBOL, DATAFLEX, SQLWINDOWS, CENTURA, PERL, PHP, JAVA J2EE.

• SQL SERVER, INFORMIX, ORACLE, MYSQL, POSTGRESQL, FIREBIRD, DB2.

– Experiência com replicação desde 1997• Replicadores: SQL Server, Informix, Postgresql, ObjectMMRS

(qualquer SGBD).• Idealizador e desenvolvedor do software ObjectMMRS (Object

Multi-Master Replication Server)


Conceitos de Replicação

• O que é replicação de banco de dados ?Copiar dados de forma gerenciada entre

servidores de banco de dados localizados em rede local ou conectados via Internet / WAN.



• Para que serve ?– Backup contínuo de banco de dados.– Balanceamento de carga.– Descentralização.– Integração entre sistemas heterogêneos.– Data warehousing



• Quais os benefícios ?– Melhor desempenho– Melhor disponibilidade– Redução de custos– Minimização de problemas decorrentes da

integração tardia entre sistemas heterogêneos



• Quais os problemas ?– Maior complexidade– Necessidade de monitoramento– DBAs experientes– Inconsistências temporárias



• Tipos de Replicação– Síncrona (Eager)

• Exemplo: Conta Corrente de Bancos, Reservas Aéreas, etc.

• Consistência total das transações entre servidores.• Indisponibilidade de todos os servidores em caso de

queda de rede• Alto custo• Baixa escalabilidade• Para aplicações que necessitam dos dados

atualizados em todos os servidores imediatamente



• Tipos de Replicação– Assíncrona (Lazy)

• Exemplo: Comércio varejista em geral, Fábricas.• Inconsistência temporária dos dados entre os

servidores• Resistente a quedas de rede• Baixo custo• Alta escalabilidade• Para aplicações que não exigem atualização

simultânea em todos os servidores



• Tipos de Replicação– Unidirecional (Master-Slave)

• Backup, Balanceamento de carga.• Apenas uma base recebe atualizações, as outras

são apenas para consulta ou stand-by.



• Tipos de Replicação– Bidirecional (Multi-Master)

• Descentralização, Aumento de desempenho, Aumento de disponibilidade.

• Todas as bases podem receber atualizações.



• Possíveis combinações– Síncrona Unidirecional

• Backup, balanceamento de carga para aplicações que exigem consistência total instantânea. (Bancos)

– Síncrona Bidirecional• Descentralização onde a aplicação exige consistência total

instantânea. (Bancos)

– Assíncrona Unidirecional• Backup, balanceamento para aplicações que permitam

inconsistência temporária. (Comércio e Indústria)

– Assíncrona Bidirecional• Descentralização onde aplicação permita inconsistência

temporária. (Comércio e Indústria)



• Topologias– Rede (peer-to-peer)

• Todos replicam para todos, sem a existência de um “central”, exemplo: Games, empresas totalmente descentralizadas, etc.



• Topologias– Estrela

• Existe um servidor “central”, exemplo: Matriz e filiais.



• Topologias– Hierárquica

• Vários servidores centrais, organizados em níveis, exemplo: 1 servidor para cada Estado, 1 servidor para cada município, 1 servidor em cada hospital.


Qual replicação usar

• Síncrona ? – Custo/benefício muito ruim, interessante apenas para

hot-backup ou balanceamento de carga em aplicações que não admitem inconsistência temporal

• Assíncrona ? – SIM, a melhor solução em 99% dos casos, o melhor

custo/benefício.• Backup

• Descentralização

• Balanceamento de carga


Qual replicador usar ?

• Replicadores nativos dos SGBDs ?– A maioria utiliza recursos de baixo nível, tais como leitura de logs

de transações do SGBD.– Bom desempenho.– Complexo de instalar, configurar, monitorar e principalmente

entender o que ocorre nos casos de problemas (caixa preta).– Cada SGBD implementa replicação de forma completamente

diferente e particular.

• Replicadores multiplataformas– Procuram não usar recursos de baixo nível dos SGBDs,

garantindo assim maior compatibilidade.– Desempenho pode ser menor que os nativos.– Mais simples de instalar, configurar e monitorar.– Conhecimento adquirido com o replicador pode ser usado em

outros SGBDs.


Base centralizada x descentralizada

Falhas em um banco de dados não comprometem a empresa toda

Possibilidade de parar a empresa toda

Alta escalabilidadeBaixa escalabilidade

Alto desempenhoBaixo desempenho

Maior disponibilidadeMenor disponibilidade

Baixo custo (apenas mais MO)Alto custo (rede, servidor)

Administração mais complexaAdministração simples

Bases descentralizadas(Replicação assíncrona)

Base centralizada

Comparativo considerando situação de empresas com usuários de sistemas em mais de um local físico


Adaptações no modelo de dados

• Quais cuidados na hora de fazer o modelo de dados para poder usar replicação no futuro ?

• Condição básica: Definir formalmente chaves primárias e chaves estrangeiras para garantir a integridade dos dados.

• Chaves primárias formadas por IDs (sequence, serial, etc). Usar faixas diferentes de números.

• Chaves primárias compostas com o ID do local/filial.• Chaves primárias com possibilidade de conflitos. Exemplo:

Tabela de usuários, com chave = loginname. Contornar o conflito na aplicação.

• Triggers totalizadoras.• Eliminar possibilidade de inconsistências causadas por ordem

incorreta de atualizações. (Saldos)


Adaptações na aplicação

• Quais são as transações críticas ?– Atualizações de saldos (estoque, contabilidade, financeiro, etc)– Inclusão em tabela com chave primária informada pelo usuário.

(Tratar ou deixar a estatística resolver)

• Problema comum: Usar o banco de dados como memória auxiliar– Muitas aplicações usam as tabelas do banco como memória

auxiliar, tentar identificar de alguma forma para não replicar desnecessariamente (Exemplo: Excluir e incluir itens em pedidos)


Adaptações na aplicação

• Como deve ser uma aplicação para suportar o comportamento assíncrono ?

– Transações críticas com possibilidade de conflito devem ser isoladas, executadas em apenas um determinado servidor para um determinado conjunto de dados. Exemplo: posição de estoque, criação de logins, etc. Temos duas possibilidades para tratar o problema:

1. Usuário utiliza app remotamente via terminal server, web, etc e apenas esta app utiliza a transação crítica. (ou seja, centraliza algumas operações)

2. Solução melhor: Trabalhar assíncronamente - cria-se uma transação de “request” de determinada transação crítica, este “request” é replicado para um servidor central, o servidor central processa este “request”, e depois este “request” atualizado é retornado para o servidor remoto, onde pode ser consultado para saber se o “request” foi ou não atendido.


Resolvendo uma transação crítica em multi-master assíncrono

Loja Produto Saldo

01 CD-Player 1

02 CD-Player 2

Servidor da Loja 01Tabela: ESTOQUE

Loja Produto Saldo

01 CD-Player 1

02 CD-Player 2

Servidor da Loja 02Tabela: ESTOQUE

Cenário: Cliente na loja 01 quer comprar 3 unidades de CD-Player.

Sequência correta de operações para evitar conflito:

1-Vendedor consulta posição de estoque e vê que tem 1 unidade na loja e 2 unidades na loja 02, informa esta situação ao cliente e diz que ele precisa aguardar a confirmação.2-Vendedor registra o pedido, o item fica com Flag=Pendente3-Trigger em ITEMPEDIDO grava RESERVA de 1 unidade na loja 01 e 2 unidades para a loja 02.4-Trigger em RESERVA ao ver uma reserva para um item da propria loja da baixa no saldo do ESTOQUE da loja 01 e Flag da Reserva=Atendido.5-RESERVA é replicada para a loja 02 assim como o novo saldo do item na loja 01.6-Trigger de RESERVA na loja 02 vê que é reserva de item da própria loja e da baixa no saldo do item e muda o Flag da RESERVA para Atendido.7-Esta atualização no Flag de RESERVA é replicada de volta para a loja 01.8-Trigger de RESERVA na loja 01 verifica a mudança no Flag, verifica se tem outras reservas pendentes para o mesmo item de pedido, se não tiver Flag de ITEMPEDIDO vai para Atendido.9-Vendedor consulta pedido até ver que todos os itens foram atendidos e finaliza venda.

Produto Qtde Flag

CD-Player 3 P

Tabela: ITEMPEDIDO

Loja Produto Qtde Flag

01 CD-Player 1 A

02 CD-Player 2 P

Tabela: RESERVA


CASE de sucesso

• ERP da CIGS Sistemas usando o banco de dados Firebird 2.0 e o replicador ObjectMMRS.

www.cigs.com.br

[email protected]

+55 11 5034-0807


CIGS Sistemas e ObjectMMRS

• ERP da CIGS desenvolvido em Delphi

• Gestão de vendas, estoque, contas a pagar, contas a receber, chão-de-fábrica, faturamento, etc.

• Modelo de dados com 160 tabelas

• Firebird 2.0



• O que levou a CIGS a procurar uma solução de replicação ?

“PROCURAMOS ESSA SOLUÇÃO POR CAUSA DE UM CLIENTE QUE POSSUI 3 PLANTAS. UMA FICA NA ZONA SUL DE SÃO PAULO E AS OUTRAS DUAS FICAM EM MOGI DAS CRUZES.

A PLANTA DE SÃO PAULO POR SER A MATRIZ NECESSITA QUE TODAS AS INFORMAÇÕES LANÇADAS NAS PLANTAS DE MOGI DAS CRUZES SEJAM ATUALIZADAS EM SEU BANCO DE DADOS.

A INTERNET NAS 3 PLANTAS SÃO DE PÉSSIMA QUALIDADE, CAINDO COM BASTANTE FREQUENCIA IMPOSSIBILITANDO ASSIM UM ACESSO DIRETO AO BANCO DE DADOS DA MATRIZ.

COM A AJUDA DO REPLICADOR ESSE PROBLEMA NÃO EXISTE MAIS, POIS A MEDIDA QUE A INTERNET ESTA ATIVA O REPLICADOR SE ENCARREGA DE ATUALIZAR OS DADOS NA MATRIZ E VICE-VERSA.”



• Quais modificações na base de dados foram necessárias para usar com sucesso o replicador ObjectMMRS ? – "FORAM NECESSÁRIAS VÁRIAS MUDANÇAS NO BD, COMO

CRIAÇÃO DE PK'S, FK'S E AJUSTES EM TRIGGERS."

• Quais modificações na aplicação foram necessárias para usar com sucesso o replicador ObjectMMRS ? – "FORAM FEITAS PEQUENAS MUDANÇAS PARA QUE O REPLICADOR

FUNCIONASSE COM SUCESSO. ENTRE ELAS ALGUNS AJUSTES NA NUMERAÇÃO AUTOMÁTICA EM DETERMINADOS CADASTROS E TELAS DE MOVIMENTAÇÕES."

• O sistema já estava pronto quando conheceu o replicador ? Ou o sistema foi feito após conhecer o replicador ? Quais cuidados teria hoje se fosse começar um sistema novo o qual pudesse a vir a usar replicação de banco de dados ? – "O SISTEMA JÁ ESTAVA PRONTO. HOJE TERIAMOS MAIS CUIDADO

NA CRIAÇÃO DE TABELAS E NA CRIÇÃO DE SUAS PK'S E FK'S."



• Quantos usuários do sistema ERP cada site possui ?– MATRIZ = 18

FILIAL 1 = 11FILIAL 2 = 07

• Dados mais replicados– Cadastros

• Clientes, Fornecedores, Produtos, Listas de Preços, Grades de Produtos, Processos de Produtos, e muitas outras.

– Movimentos• Pedidos de Compras e Vendas, Requisições de Materiais,

Recebimento de Mercadorias, Expedição de Mercadorias, Contas a Pagar, Contas a Receber, Movimentações Bancárias.

• Topologia– Estrela (Matriz e 2 filiais replicando apenas para a matriz)

• Implantação: Janeiro/2008



• Com a descentralização do sistema, houve aumento de problemas para o cliente final ? Houve aumento na quantidade de demanda por suporte técnico ? Podemos dizer que o aumento de trabalho compensa ?"COM A IMPLANTAÇÃO DO REPLICADOR FOI NECESSÁRIO CRIAR

FERRAMENTAS INTERNAS DE MONITORAMENTO PARA AUDITORIA.

HOJE É GERADO UM RELATÓRIO CONTENDO UM RESUMO DE TODA A MOVIMENTAÇÃO DE DADOS GERADOS DURANTE UM DETERMINADO PERÍODO.

HAVENDO ALGUMA DIVERGENCIA O SUPORTE TÉCNICO É ACIONADO.

ALÉM DISSO DIARIAMENTE É FEITO UMA AUDITORIA NOS LOGS DO REPLICADOR PARA VER SE O HOUVE ALGUMA ANOMALIA DURANTE A REPLICAÇÃO.

MESMO COM TODO ESSE PROCEDIMENTO AINDA É MUITO VANTAJOSO O USO DO REPLICADOR, POIS COM A CORRETA ESTRUTURAÇÃO DA BASE DE DADOS OS INDICES DE ANOMALIAS SÃO QUASE ZERO."


ObjectMMRS

• Replicador assíncrono e bidirecional de banco de dados

• Compatível com Firebird 1.5, 2.X

• Pode replicar dados de Firebird para outros SGBDs e vice-versa (PostgreSQL, MySQL, Oracle, DB2, MS SQLServer, etc)

• Free para replicar entre 2 servidores.

• Download disponível em www.object.com.br

• Suporte técnico gratuito para testes.


Sugestões

• Não tente usar replicação de dados se seu modelo de dados não está com chaves primárias e estrangeiras formalmente definidas.

• Procure estudar o que precisa ser replicado para cada servidor, na maioria das vezes não é necessário replicar todas as tabelas para todos os servidores.

• Não existe ainda uma forma de avaliar qual a banda de rede necessária para o volume de dados que você quer replicar, portanto TESTE ANTES !

• Não existe mágica, resolução automática de conflitos anunciada por alguns replicadores não resolvem, projete a sua aplicação para evitar conflitos.

• Não compre nenhuma solução de replicação de banco de dados que você não possa testar bem antes, o software talvez não seja adequado ou compatível com o seu tipo de aplicação.

• A complexidade na administração do ambiente replicado é recompensada pela satisfação dos usuários com o alto desempenho e a alta disponibilidade proporcionados por bases locais.


Questões

– Quer compartilhar alguma experiência com replicação no Firebird ?

– Dúvidas ?– Se quiser escrever: [email protected]


FIM

• Agradeço a todos os participantes da palestra !!

• Agradecimentos especiais: – Equipe do banco de dados Open-Source Firebird

– Equipe organizadora deste evento (Firebase)

– CIGS Sistemas por fornecer dados sobre o CASE de uso do ObjectMMRS e por ser pioneira no ObjectMMRS em plataforma Firebird 2.

– Sérgio Luiz da Control-M e Luis Cardoso da Indusoft pela grande ajuda durante a compatibilização do ObjectMMRS com o Firebird 1.5

www.object.com.br

Documents

Www.FirebirdDevelopersDay.com.br © 2008 – Wagner Corrêa Ramos 1 Bem-vindo ao Firebird Developers Day 2008 “Aumentando a disponibilidade e o desempenho