Wagner Corrêa Ramos
Anderson Massaharu Shibata
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

Disponibilidade total com replicação bidirecional e PostgreSQL
2
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.
Disponibilidade total com replicação bidirecional e PostgreSQL
3
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
Disponibilidade total com replicação bidirecional e PostgreSQL
4
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.
Disponibilidade total com replicação bidirecional e PostgreSQL
5
PostgreSQL Bidirecional / Multi-Master
usando ObjectMMRS

Exemplo de conflito de INSERT
Disponibilidade total com replicação bidirecional e PostgreSQL
6
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.
Disponibilidade total com replicação bidirecional e PostgreSQL
7
PostgreSQL Bidirecional / Multi-Master
usando ObjectMMRS

Exemplo de conflito de UPDATE em Multi-Master
Disponibilidade total com replicação bidirecional e PostgreSQL
8
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.
Disponibilidade total com replicação bidirecional e PostgreSQL
9
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.
Disponibilidade total com replicação bidirecional e PostgreSQL
10
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 multimaster dia a dia.
 O servidor central, antes com o papel principal na arquitetura
passou a ser apenas um servidor de contingência.
Disponibilidade total com replicação bidirecional e PostgreSQL
11
PostgreSQL Bidirecional / Multi-Master
usando ObjectMMRS

Problemas durante o processo de mudança para multimaster
 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.
Disponibilidade total com replicação bidirecional e PostgreSQL
12
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.
Disponibilidade total com replicação bidirecional e PostgreSQL
13
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.
 Emails 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
Disponibilidade total com replicação bidirecional e PostgreSQL
14
PostgreSQL Bidirecional / Multi-Master
usando ObjectMMRS

Tela principal do ObjectMMRS WebAdmin
Disponibilidade total com replicação bidirecional e PostgreSQL
15
PostgreSQL Bidirecional / Multi-Master
usando ObjectMMRS

Zabbix monitorando as filas do ObjectMMRS
Disponibilidade total com replicação bidirecional e PostgreSQL
16
Prós e Contras de cada arquitetura
Item analizado
Banco
MasterCentralizado Slave
(Slony-I)
Multi-Master
(ObjectMMRS)
Arquitetura
Simples
Média
Complexa
Risco de parada total
Alto
Zero
Zero
Risco de parada parcial
Alto
Alto
Zero
Necessidade de Banda de rede
Alta
Média
Baixa
Necessidade de Estabilidade
de rede
Alta
Média
Baixa
Sobrecarga no Servidor Central
Alta
Média
Baixa
Custos Totais
Alto
Médio
Baixo
Disponibilidade total com replicação bidirecional e PostgreSQL
17
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 email
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)
Disponibilidade total com replicação bidirecional e PostgreSQL
18
Comentários e Questões
Disponibilidade total com replicação bidirecional e PostgreSQL
19
Obrigado a todos !

Contatos
 [email protected]
 [email protected]
 www.object.com.br
 www.objectmmrs.com
 www.shibata.com.br
Disponibilidade total com replicação bidirecional e PostgreSQL
20