A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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

Apresentações semelhantes


Apresentação em tema: "Www.FirebirdDevelopersDay.com.br © 2008 – Wagner Corrêa Ramos 1 Bem-vindo ao Firebird Developers Day 2008 “Aumentando a disponibilidade e o desempenho."— Transcrição da apresentação:

1 © 2008 – Wagner Corrêa Ramos 1 Bem-vindo ao Firebird Developers Day 2008 “Aumentando a disponibilidade e o desempenho usando replicação de dados” Wagner Corrêa Ramos OBJECT Sistemas

2 © 2008 – Wagner Corrêa Ramos 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 © 2008 – Wagner Corrêa Ramos 3 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)‏

4 © 2008 – Wagner Corrêa Ramos 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 © 2008 – Wagner Corrêa Ramos 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 © 2008 – Wagner Corrêa Ramos 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 © 2008 – Wagner Corrêa Ramos 7 Conceitos de Replicação Quais os problemas ? –Maior complexidade –Necessidade de monitoramento –DBAs experientes –Inconsistências temporárias

8 © 2008 – Wagner Corrêa Ramos 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 © 2008 – Wagner Corrêa Ramos 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 © 2008 – Wagner Corrêa Ramos 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 © 2008 – Wagner Corrêa Ramos 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 © 2008 – Wagner Corrêa Ramos 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 © 2008 – Wagner Corrêa Ramos 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 © 2008 – Wagner Corrêa Ramos 14 Conceitos de Replicação Topologias –Estrela Existe um servidor “central”, exemplo: Matriz e filiais.

15 © 2008 – Wagner Corrêa Ramos 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 © 2008 – Wagner Corrêa Ramos 16 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

17 © 2008 – Wagner Corrêa Ramos 17 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 © 2008 – Wagner Corrêa Ramos 18 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

19 © 2008 – Wagner Corrêa Ramos 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 © 2008 – Wagner Corrêa Ramos 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 © 2008 – Wagner Corrêa Ramos 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: 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.

22 © 2008 – Wagner Corrêa Ramos 22 Resolvendo uma transação crítica em multi-master assíncrono LojaProdutoSaldo 01CD-Player1 02CD-Player2 Servidor da Loja 01 Tabela: ESTOQUE LojaProdutoSaldo 01CD-Player1 02CD-Player2 Servidor da Loja 02 Tabela: 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=Pendente 3-Trigger em ITEMPEDIDO grava RESERVA de 1 unidade na loja 01 e 2 unidades para a loja 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 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 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. ProdutoQtdeFlag CD-Player3P Tabela: ITEMPEDIDO LojaProdutoQtdeFlag 01CD-Player1A 02CD-Player2P Tabela: RESERVA

23 © 2008 – Wagner Corrêa Ramos 23 CASE de sucesso ERP da CIGS Sistemas usando o banco de dados Firebird 2.0 e o replicador ObjectMMRS

24 © 2008 – Wagner Corrêa Ramos 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 © 2008 – Wagner Corrêa Ramos 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 © 2008 – Wagner Corrêa Ramos 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 © 2008 – Wagner Corrêa Ramos 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 © 2008 – Wagner Corrêa Ramos 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 © 2008 – Wagner Corrêa Ramos 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 © 2008 – Wagner Corrêa Ramos 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 © 2008 – Wagner Corrêa Ramos 31 Questões –Quer compartilhar alguma experiência com replicação no Firebird ? –Dúvidas ? –Se quiser escrever:

32 © 2008 – Wagner Corrêa Ramos 32 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


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

Apresentações semelhantes


Anúncios Google