1 / 20

DISPONIBILIDADE TOTAL COM REPLICAÇÃO BIDIRECIONAL E POSTGRESQL

Wagner Corrêa Ramos Anderson Massaharu Shibata. 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)

bisa
Télécharger la présentation

DISPONIBILIDADE TOTAL COM REPLICAÇÃO BIDIRECIONAL E POSTGRESQL

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related