Wagner Corrêa Ramos OBJECT Sistemas object.br

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

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

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

23. CASE de sucesso • ERP da CIGS Sistemas usando o banco de dados Firebird 2.0 e o replicador ObjectMMRS. www.cigs.com.br comercial@cigs.com.br +55 11 5034-0807

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 = 18FILIAL 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

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 www.object.com.br • 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. Questões • Quer compartilhar alguma experiência com replicação no Firebird ? • Dúvidas ? • Se quiser escrever: wagner@object.com.br

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 www.object.com.br