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

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

Wagner Corrêa Ramos Anderson Massaharu Shibata. Disponibilidade total com replicação bidirecional e PostgreSQL Agenda Apresentação da Rede de Supermercados.

Apresentações semelhantes


Apresentação em tema: "Wagner Corrêa Ramos Anderson Massaharu Shibata. Disponibilidade total com replicação bidirecional e PostgreSQL Agenda Apresentação da Rede de Supermercados."— Transcrição da apresentação:

1 Wagner Corrêa Ramos Anderson Massaharu Shibata

2 Disponibilidade total com replicação bidirecional e PostgreSQL Agenda Apresentação da Rede de Supermercados Shibata (5 min) PostgreSQL Centralizado e Master-Slave (5 min) PostgreSQL Bidirecional / Multi-Master (20 min) Prós e Contras de cada abordagem (10 min) Comentários e Questões 2

3 Disponibilidade total com replicação bidirecional e PostgreSQL PostgreSQL Bidirecional / Multi-Master Qual a motivação para utilizar a arquitetura Multi-Master ? Problemas frequentes de internet 2009: 2 eventos de parada do servidor central, cada parada traduzida em 6 horas sem sistemas de retaguarda (um destes eventos próximo do Natal) 2009: Muitos periodos de lentidão, foram os primeiros sinais que a abordagem master-slave não aguentaria por muito tempo, pensando no crescimento do grupo Shibata. Na abordagem master-slave, o uso dos sistemas em eventos de parada de rede ou servidor central não era completo, permitindo aos usuários remotos fazerem apenas consultas, nenhuma atualização, então os sistemas ficavam apenas parcialmente disponíveis. Como usuários sempre querem mais da TI, o grupo passou a procurar por uma solução melhor de alta disponibilidade. 3

4 Disponibilidade total com replicação bidirecional e PostgreSQL PostgreSQL Bidirecional / Multi-Master Tentativa com PgCluster – muito complexo ObjectMMRS ? O que fez diferença para a escolha ? Suporte a falhas de internet Flexibilidade e transparência: Pode misturar versões de Pg, CDC (change-data-capture) baseado em triggers comuns, boa documentação das tabelas de uso interno do replicador. Baixo overhead: Embora a sobrecarga do CDC baseado em trigger, a distribuição dos dados é leve. O load do servidor quando comparado com o Slony é baixo. Comparado com as outras soluções o ObjectMMRS é um dos mais simples. Suporte técnico qualificado 4

5 Disponibilidade total com replicação bidirecional e PostgreSQL PostgreSQL Bidirecional / Multi-Master Preparação do Multi-Master Testes do ObjectMMRS com ERP SHIBATA com 3 servidores PostgreSQL e todas as principais operações do ERP. O modelo de dados do ERP usa IDs artificiais em todas as PKs. Para evitar conflitos de INSERT / PK em multi-master assíncrono temos 2 alternativas: Fazer PK composta com o ID da loja ou trabalhar com faixas de valores não conflitantes. Nós adotamos o mais simples, não mexer na PK e trabalhar com faixas de IDs não conflitantes. Mudamos o tipo de dados do ID de INTEGER para BIGINT porque algumas tabelas estavam já bem grandes, no total o modelo de dados contém 450 tabelas. 5

6 Disponibilidade total com replicação bidirecional e PostgreSQL PostgreSQL Bidirecional / Multi-Master usando ObjectMMRS Exemplo de conflito de INSERT 6

7 Disponibilidade total com replicação bidirecional e PostgreSQL PostgreSQL Bidirecional / Multi-Master usando ObjectMMRS Preparação para Multi-Master Tinhamos 2 opções para evitar conflitos de UPDATE: Identificar e isolar as operações de UPDATE com possibilidade de conflito (update simultâneo), ou usar o recurso de identificação e tratamento de conflito de UPDATE do ObjectMMRS. Escolhemos isolar as possibilidades de conflitos. Opção mais simples. Em Multi-Master sempre que puder tratar o conflito de update evitando-o é a melhor escolha. Trabalhe como em um banco de dados particionado, onde cada local atualiza o seu próprio dado, e as operações realmente com muita chance de conflito execute-as de forma centralizada. 7

8 Disponibilidade total com replicação bidirecional e PostgreSQL PostgreSQL Bidirecional / Multi-Master usando ObjectMMRS Exemplo de conflito de UPDATE em Multi-Master 8

9 Disponibilidade total com replicação bidirecional e PostgreSQL PostgreSQL Bidirecional / Multi-Master usando ObjectMMRS Preparação para o Multi-Master O ERP Shibata não usa triggers, então as únicas triggers passaram a ser as triggers de CDC do prróprio ObjectMMRS. Passamos 2 meses planejando e testando para o dia D. É muito importante realizar muitos testes antes de colocar em produção um projeto multi-master. A adoção da arquitetura multi-master no Shibata foi facilitada porque eles tem o domínio completo da aplicação, com isso foi rápido identificar pontos de conflito em potencial. 9

10 Disponibilidade total com replicação bidirecional e PostgreSQL PostgreSQL Bidirecional / Multi-Master usando ObjectMMRS Passos para mudar de Master-Slave para Multi-Master Fizemos toda a instalação e configuração do ObjectMMRS enquanto o Slony-I continuava replicando. Criamos o dicionário de dados do ObjectMMRS em todas as bases. Criamos as triggers de CDC do ObjectMMRS. Depois de tudo instalado, configurado e conferido nós paramos o Slony-I e o ERP. Ficamos cerca de 1 hora sem replicar mas apenas 5 minutos com o ERP parado. (Apenas o tempo para rodar os scripts de criação das triggers e esvaziar as filas do Slony) Ficamos 3 dias acompanhando a replicação e usando o ERP ainda de forma master-slave. 10

11 Disponibilidade total com replicação bidirecional e PostgreSQL PostgreSQL Bidirecional / Multi-Master usando ObjectMMRS Finalmente Multi-Master Após 3 dias de conferência dos dados, passamos a primeira loja para usar o sistema de forma multi-master. Após acompanhar o trabalho multi-master por 1 dia e ver que estava tudo ok passamos a colocar as outras lojas em multi- master dia a dia. O servidor central, antes com o papel principal na arquitetura passou a ser apenas um servidor de contingência. 11

12 Disponibilidade total com replicação bidirecional e PostgreSQL PostgreSQL Bidirecional / Multi-Master usando ObjectMMRS Problemas durante o processo de mudança para multi- master Alguns usuários usavam o ERP acessando o servidor local e o central de forma aleatória, com isso chegavam a achar que o sistema havia perdido informações porque por exemplo criavam uma NF de entrada no central e depois iam dar andamento no processo de entrada no estoque usando o servidor local e não achavam a NF. Este tipo de situação pode ocorrer por causa do tempo de propagação dos dados via WAN. Poderiamos ter evitado este tipo de problema bloqueando o acesso ao servidor central, mas foi melhor contornado apenas com treinamento aos usuários, assim o servidor central fica sempre disponível sem nenhuma necessidade de liberação para uso. 12

13 Disponibilidade total com replicação bidirecional e PostgreSQL PostgreSQL Bidirecional / Multi-Master usando ObjectMMRS Benefícios imediatos do Multi-Master Cumprimentos do usuário final dizendo que o sistema nunca esteve tão rápido (reflexo de usar sistema em LAN em vez de WAN) O usuário final nem sabe quando a internet esta ou não com problemas, pois ele sempre usa o sistema no servidor local. Você pode parar o servidor central por 5 minutos ou horas para manutenção, tuning, etc, e ninguém vai perceber. Pode fazer o mesmo com servidor local direcionando os usuários para o servidor central. Tráfego de rede diminuído, liberando banda de rede para outros usos. 13

14 Disponibilidade total com replicação bidirecional e PostgreSQL PostgreSQL Bidirecional / Multi-Master usando ObjectMMRS Operação no dia a dia O OBJECTMMRS tem um painel web que monitora a replicação informando quais servidores estão online e os tamanhos de filas. s são enviados aos DBAs informando anormalidades No caso de uma pane em um servidor local: Os usuários ficam usando o servidor central enquanto é feita a manutenção do servidor local Se o servidor local não puder ser recuperado rapidamente, um servidor backup é deslocado para a loja. Mantemos 3 backups sempre atualizados para atender as 11 lojas. Após concluída a troca do servidor os usuários voltam a usar o sistema localmente Temos assim ZERO de parada e máxima disponibilidade 14

15 Disponibilidade total com replicação bidirecional e PostgreSQL PostgreSQL Bidirecional / Multi-Master usando ObjectMMRS Tela principal do ObjectMMRS WebAdmin 15

16 Disponibilidade total com replicação bidirecional e PostgreSQL PostgreSQL Bidirecional / Multi-Master usando ObjectMMRS Zabbix monitorando as filas do ObjectMMRS 16

17 Disponibilidade total com replicação bidirecional e PostgreSQL Prós e Contras de cada arquitetura Item analizadoBanco Centralizado Master- Slave (Slony-I) Multi-Master (ObjectMMRS) ArquiteturaSimplesMédiaComplexa Risco de parada totalAltoZero Risco de parada parcialAlto Zero Necessidade de Banda de redeAltaMédiaBaixa Necessidade de Estabilidade de rede AltaMédiaBaixa Sobrecarga no Servidor CentralAltaMédiaBaixa Custos TotaisAltoMédioBaixo 17

18 Disponibilidade total com replicação bidirecional e PostgreSQL Sobre o ObjectMMRS Tecnologia Protocolo Lazy update anywhere with timestamp update conflict detection and resolution Licenciamento Licença anual incluindo upgrades e suporte técnico por Corporate – Ilimitado número de servidores Enterprise – Mais de 1 milhão de INSERT/UPDATE/DELETEs / dia. Standard – Menos de 1 milhão de operações / dia. Preço a partir de R$ 900 anual por base de dados. Mobile – SQLite em smartphones, tablets, etc. Serviços Treinamento Adequação de aplicação, Provas de conceito, Instalação Suporte técnico (Telefone, Acesso remoto, Chat, Local) 18

19 Disponibilidade total com replicação bidirecional e PostgreSQL Comentários e Questões 19

20 Disponibilidade total com replicação bidirecional e PostgreSQL Obrigado a todos ! Contatos 20


Carregar ppt "Wagner Corrêa Ramos Anderson Massaharu Shibata. Disponibilidade total com replicação bidirecional e PostgreSQL Agenda Apresentação da Rede de Supermercados."

Apresentações semelhantes


Anúncios Google