Wagner Corrêa Ramos OBJECT Sistemas

Apresentação em tema: "Wagner Corrêa Ramos OBJECT Sistemas"— Transcrição da apresentação:

1 Wagner Corrêa Ramos OBJECT Sistemas http://www.object.com.br
Bem-vindo ao Firebird Developers Day “Aumentando a disponibilidade e o desempenho usando replicação de dados” Wagner Corrêa Ramos OBJECT Sistemas

2 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

3 Wagner Corrêa Ramos Apresentação 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)‏

4 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.

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

6 Conceitos de Replicação
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

7 Conceitos de Replicação
Quais os problemas ? Maior complexidade Necessidade de monitoramento DBAs experientes Inconsistências temporárias

8 Conceitos de Replicação
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

9 Conceitos de Replicação
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

10 Conceitos de Replicação
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.

11 Conceitos de Replicação
Tipos de Replicação Bidirecional (Multi-Master)‏ Descentralização, Aumento de desempenho, Aumento de disponibilidade. Todas as bases podem receber atualizações.

12 Conceitos de Replicação
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)

13 Conceitos de Replicação
Topologias Rede (peer-to-peer)‏ Todos replicam para todos, sem a existência de um “central”, exemplo: Games, empresas totalmente descentralizadas, etc.

14 Conceitos de Replicação
Topologias Estrela Existe um servidor “central”, exemplo: Matriz e filiais.

15 Conceitos de Replicação
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.

16 Síncrona ? Assíncrona ? Qual replicação usar
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

17 Replicadores nativos dos SGBDs ?
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.

18 Base centralizada x descentralizada
Comparativo considerando situação de empresas com usuários de sistemas em mais de um local físico Falhas em um banco de dados não comprometem a empresa toda Possibilidade de parar a empresa toda Alta escalabilidade Baixa escalabilidade Alto desempenho Baixo desempenho Maior disponibilidade Menor disponibilidade Baixo custo (apenas mais MO)‏ Alto custo (rede, servidor)‏ Administração mais complexa Administração simples Bases descentralizadas (Replicação assíncrona)‏ Base centralizada

19 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)

20 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)‏

21 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: 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)‏ 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.

22 Resolvendo uma transação crítica em multi-master assíncrono
Servidor da Loja 01 Tabela: ESTOQUE Servidor da Loja 02 Tabela: ESTOQUE Tabela: ITEMPEDIDO Loja Produto Saldo 01 CD-Player 1 02 2 Loja Produto Saldo 01 CD-Player 1 02 2 Produto Qtde Flag CD-Player 3 P Tabela: RESERVA 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=Pendente 3-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. Loja Produto Qtde Flag 01 CD-Player 1 A 02 2 P

23 CASE de sucesso ERP da CIGS Sistemas usando o banco de dados Firebird 2.0 e o replicador ObjectMMRS.

24 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

25 CIGS Sistemas e ObjectMMRS
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.”

26 CIGS Sistemas e ObjectMMRS
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."

27 CIGS Sistemas e ObjectMMRS
Quantos usuários do sistema ERP cada site possui ? MATRIZ = 18 FILIAL 1 = 11 FILIAL 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

28 CIGS Sistemas e ObjectMMRS
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."

29 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 Suporte técnico gratuito para testes.

30 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.

31 Quer compartilhar alguma experiência com replicação no Firebird ?
Questões Quer compartilhar alguma experiência com replicação no Firebird ? Dúvidas ? Se quiser escrever:

32 www.object.com.br Agradeço a todos os participantes da palestra !!
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