DISPONIBILIDADE TOTAL COM REPLICAÇÃO BIDIRECIONAL E POSTGRESQL

1. Wagner Corrêa Ramos Anderson Massaharu Shibata DISPONIBILIDADE TOTAL COM REPLICAÇÃO BIDIRECIONAL E POSTGRESQL

2. Agenda Apresentação da Rede de Supermercados Shibata (5 min) PostgreSQLCentralizado e Master-Slave (5 min) PostgreSQLBidirecional / Multi-Master (20 min) Prós e Contras de cadaabordagem (10 min) Comentários e Questões

3. PostgreSQLBidirecional / Multi-Master • Quala motivaçãoparautilizar a arquitetura Multi-Master ? • Problemasfrequentes de internet • 2009: 2 eventos de parada do servidor central, cadaparadatraduzidaem 6 horassemsistemas de retaguarda (um desteseventospróximo do Natal) • 2009: Muitosperiodos de lentidão, foramosprimeirossinaisque a abordagem master-slave nãoaguentariapormuito tempo, pensando no crescimento do grupo Shibata. • Na abordagem master-slave, o uso dos sistemasemeventos de parada de redeouservidor central não era completo, permitindoaosusuáriosremotosfazeremapenasconsultas, nenhumaatualização, entãoossistemasficavamapenasparcialmentedisponíveis. Como usuáriossemprequeremmais da TI, o grupopassou a procurarporumasoluçãomelhor de altadisponibilidade.

4. PostgreSQLBidirecional / Multi-Master • Tentativa com PgCluster– muitocomplexo • ObjectMMRS? O que fez diferençapara a escolha? • Suporte a falhas de internet • Flexibilidade e transparência: Podemisturarversões de Pg, CDC (change-data-capture) baseadoem triggers comuns, boa documentação das tabelas de usointerno do replicador. • Baixo overhead: Embora a sobrecarga do CDC baseadoem trigger, a distribuição dos dados éleve. O load do servidorquandocomparado com o Slonyébaixo. • Comparado com as outrassoluções o ObjectMMRSé um dos mais simples. • Suportetécnicoqualificado

5. PostgreSQLBidirecional / Multi-Master • Preparação do Multi-Master • Testes do ObjectMMRScom ERP SHIBATA com 3 servidoresPostgreSQL e todas as principaisoperações do ERP. • O modelo de dados do ERP usa IDs artificiaisemtodas as PKs. Para evitarconflitos de INSERT / PK em multi-master assíncronotemos 2 alternativas: Fazer PK composta com o ID da lojaoutrabalhar com faixas de valoresnãoconflitantes. Nósadotamos o mais simples, nãomexerna PK e trabalhar com faixas de IDs nãoconflitantes. • Mudamos o tipo de dados do ID de INTEGER paraBIGINT porquealgumastabelasestavamjábemgrandes, no total o modelo de dados contém 450 tabelas.

6. PostgreSQLBidirecional / Multi-Master usandoObjectMMRS Exemplo de conflito de INSERT

7. PostgreSQLBidirecional / Multi-Master usandoObjectMMRS • PreparaçãoparaMulti-Master • Tinhamos 2 opçõesparaevitarconflitos de UPDATE: Identificar e isolar as operações de UPDATE com possibilidade de conflito (update simultâneo), ouusar o recurso de identificação e tratamento de conflito de UPDATE doObjectMMRS. Escolhemosisolar as possibilidades de conflitos. Opçãomais simples. • EmMulti-Master semprequepudertratar o conflito de update evitando-o é a melhorescolha. Trabalhecomoem um banco de dados particionado, ondecada local atualiza o seupróprio dado, e as operaçõesrealmente com muita chance de conflito execute-as de forma centralizada.

8. PostgreSQLBidirecional / Multi-Master usandoObjectMMRS • Exemplo de conflito de UPDATE em Multi-Master

9. PostgreSQLBidirecional / Multi-Master usandoObjectMMRS • Preparaçãopara o Multi-Master • O ERP Shibata nãousa triggers, então as únicas triggers passaram a ser as triggers de CDC do prróprioObjectMMRS. • Passamos 2 mesesplanejando e testandopara o dia D. • Émuitoimportanterealizarmuitos testes antes de colocaremprodução um projeto multi-master. • A adoção da arquitetura multi-master no Shibata foifacilitadaporqueeles tem o domíniocompleto da aplicação, com issofoirápidoidentificarpontos de conflitoempotencial.

10. PostgreSQLBidirecional / Multi-Master usandoObjectMMRS • Passosparamudar de Master-Slave paraMulti-Master • Fizemostoda a instalação e configuração do ObjectMMRSenquanto o Slony-I continuavareplicando. • Criamos o dicionário de dados do ObjectMMRSemtodas as bases. • Criamos as triggers de CDC do ObjectMMRS. • Depois de tudoinstalado, configurado e conferidonósparamos o Slony-I e o ERP. Ficamoscerca de 1 horasemreplicar mas apenas 5 minutos com o ERP parado. (Apenas o tempo pararodaros scripts de criação das triggers e esvaziar as filas do Slony) • Ficamos 3 diasacompanhando a replicação e usando o ERP ainda de forma master-slave.

11. PostgreSQLBidirecional / Multi-Master usandoObjectMMRS • Finalmente Multi-Master • Após 3 dias de conferência dos dados, passamos a primeiralojaparausar o sistema de forma multi-master. • Apósacompanhar o trabalho multi-master por 1 dia e verqueestavatudo ok passamos a colocar as outraslojasem multi-master dia a dia. • O servidor central, antes com o papel principal naarquiteturapassou a serapenas um servidor de contingência.

12. PostgreSQLBidirecional / Multi-Master usandoObjectMMRS • Problemasdurante o processo de mudançaparamulti-master • Algunsusuáriosusavam o ERP acessando o servidor local e o central de forma aleatória, com issochegavam a acharque o sistemahaviaperdidoinformaçõesporqueporexemplocriavamuma NF de entrada no central e depoisiamdarandamento no processo de entrada no estoqueusando o servidor local e nãoachavam a NF. Este tipo de situaçãopodeocorrerporcausa do tempo de propagação dos dados via WAN. • Poderiamosterevitadoestetipo de problemabloqueando o acessoaoservidor central, mas foimelhorcontornadoapenas com treinamentoaosusuários, assim o servidor central ficasempredisponívelsemnenhumanecessidade de liberaçãoparauso.

13. PostgreSQLBidirecional / Multi-Master usandoObjectMMRS • Benefíciosimediatos do Multi-Master • Cumprimentos do usuário final dizendoque o sistemanuncaestevetãorápido (reflexo de usarsistemaem LAN emvez de WAN) • O usuário final nemsabequando a internet estaounão com problemas, poiselesempreusa o sistema no servidor local. • Vocêpodeparar o servidor central por 5 minutosouhorasparamanutenção, tuning, etc, e ninguémvaiperceber. • Podefazer o mesmo com servidor local direcionandoosusuáriospara o servidor central. • Tráfego de redediminuído, liberandobanda de redepara outros usos.

14. PostgreSQLBidirecional / Multi-Master usandoObjectMMRS • Operação no dia a dia • O OBJECTMMRS tem um painel web quemonitora a replicaçãoinformandoquaisservidoresestão online e ostamanhos de filas. • Emails sãoenviadosaos DBAs informandoanormalidades • No caso de uma pane em um servidor local: • Osusuáriosficamusando o servidor central enquantoéfeita a manutenção do servidor local • Se o servidor local nãopuderserrecuperadorapidamente, um servidor backup édeslocadopara a loja. Mantemos 3 backups sempreatualizadosparaatender as 11 lojas. • Apósconcluída a troca do servidorosusuáriosvoltam a usar o sistemalocalmente • Temosassim ZERO de parada e máximadisponibilidade

15. PostgreSQLBidirecional / Multi-Master usandoObjectMMRS Tela principal doObjectMMRSWebAdmin

16. PostgreSQLBidirecional / Multi-Master usandoObjectMMRS Zabbixmonitorando as filas do ObjectMMRS

17. Prós e Contras de cadaarquitetura

18. Sobre o ObjectMMRS • Tecnologia • Protocolo “Lazy update anywhere with timestamp update conflict detection and resolution” • Licenciamento • Licençaanualincluindo upgrades e suportetécnicopor email • Corporate – Ilimitadonú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 anualpor base de dados. • Mobile – SQLite em smartphones, tablets, etc. • Serviços • Treinamento • Adequação de aplicação, Provas de conceito, Instalação • Suportetécnico (Telefone, Acessoremoto, Chat, Local)

19. Comentários e Questões

20. Obrigado a todos ! • Contatos • wagner@object.com.br • anderson@object.com.br • www.object.com.br • www.objectmmrs.com • www.shibata.com.br