Topologias de Replicação do MySQL 5.1: Multi-mestre

Question

Olá, - -)

Mais uma vez, estou à procura de novos conhecimentos, sou um DBA em meio período como parte do meu trabalho atual e estou particularmente interessado em qualquer documentação ou leitura em torno de fazer multi à prova de balas topologias de replicação -master - alguém tem alguma ponteira?

Em funções passadas eu implementei e apoiei tais topologias, mas sempre há 'capturas' (auto_increment_increment, auto_increment_offset sendo duas grandes ) que você só identifica no último minuto e que tem um potencial sério arruinar o seu dia.

Com uma grande carga de trabalho do InnoDB, quais são os grandes problemas com a replicação multimestre e como você, como um DBA habilidoso, resolve os problemas? Como essa imagem muda se você estiver armazenando coisas com o MyISAM, ou mesmo com outros mecanismos de armazenamento, agora eles são legais e conectáveis, talvez alguém tenha experiência com a Infobright ou outro data warehouse?

Deve-se enfatizar as técnicas de recuperação para qualquer solução proposta. Como um DBA efetivamente faz backup dessa topologia e quão fácil é o processo de restauração? É à prova de balas o suficiente para que você possa colocar um balanceador de carga com reconhecimento de TCP (hashing no IP de origem ou similar) na frente e ter tempo de inatividade zero (ou próximo de ...) no caso de um mestre MySQL vai pop?

Eu li e recomendo o High Performance MySQL do Baron Schwartz, no entanto, o que eu realmente procuro é um par de sites realmente de qualidade com todos os pontos cobertos e links para um material de leitura mais aprofundado, conforme necessário. Quem tem um desses à mão? :)

O brownie de bônus aponta para qualquer solução que possa ter 'pools' de escravos pendurados para uma aplicação estranha que tenha uma carga de trabalho de leitura particularmente surrada.

Muito obrigado.

    

Answer 1

A replicação master-master é assíncrona, portanto, ela definitivamente será interrompida se você gravar nos dois servidores de uma só vez.

Mesmo que os incrementos automáticos estejam funcionando, qualquer outro índice exclusivo e muitas outras situações podem quebrá-lo - é muito frágil para ser usado.

Mas é possível usar master-master como PART de uma solução de HA, você só precisa garantir que os aplicativos só gravem em um dos pares e em uma situação de failover "limpa", por exemplo, quando o administrador falha, ele espera que o escravo alcance antes de comutar.

Isso não é extremamente difícil na prática, mas um pouco inconveniente.

Sua principal outra opção é usar o DRBD, que também não é muito difícil de configurar - mas, neste caso, a segunda máquina não é nem utilizável como uma réplica de leitura - ela apenas fica lá como uma peça de reposição. O DRBD replica de forma síncrona o armazenamento subjacente, portanto tudo é gravado com segurança em ambas as máquinas.

Existem algumas aplicações que são especialmente projetadas para tolerar os problemas multi-master - estas precisam ser projetadas MUITO cuidadosamente com essa exata situação em mente - neste caso, tudo bem. Você não pode usar aplicativos não projetados para isso.

o incremento automático não é o único ou o principal problema.

    

Answer 2

Obviamente, você tentou a replicação circular, considerando seus comentários sobre autoincremento. Essa seria a minha opção preferida; você só precisa lembrar de configurar o MySQL corretamente.

Você pode ver Sequioa , que funciona ao se sentar em frente ao seu cluster do mysql e lida com executando seu SQL em todos os servidores no caso de gravações e balanceamento de carga no caso de leituras. Ele tem vários outros recursos, como permitir diferentes backends de banco de dados. Não é simples, com operações que requerem várias etapas, mas você está solicitando um problema difícil, por isso não é surpresa que as soluções não sejam fáceis.