DRBD com MySQL

Question

Pergunta sobre o uso do DRBD para fornecer HA para o MySQL.

Eu preciso ter certeza de que minha instância de backup do MySQL sempre estará em um estado funcional quando ocorrer o failover. O que acontece, por exemplo, se o primário morre no meio de uma transação?

Vamos acabar com dados copiados para o secundário que o mysql não pode manipular? Ou, e se a rede desaparecer enquanto os dois estiverem sincronizando, e nem todos os dados passarem.

Parece ser possível entrar em um estado em que dados incompletos no secundário tornam impossível para o mysql iniciar e ler o banco de dados.

Estou sentindo falta de algo?

    

Answer 1

Depende, naturalmente, da natureza do failover. Também parece que você já sabe a resposta para sua pergunta.

O DRBD é, fundamentalmente, o espelhamento RAID de rede. Blocos em - > bloqueia. Você pode executar de forma síncrona ou assíncrona, dependendo dos seus requisitos de latência. Qual desses você escolhe afeta tremendamente se sua réplica é consistente ou não.

Reduzida a esse nível, sua pergunta se torna: "o que acontece quando o MySQL inicia e lê arquivos de dados?" Seus dados são bem formados e desativados, e iniciam sem problemas, ou são consistentes com falhas, e você pode ter problemas de consistência. (Há também a possibilidade de você ter corrupção no disco, é claro, e isso também pode ser um problema com o DRBD, especialmente se você de alguma forma acabar com um cenário de cérebro dividido.) Geralmente, ele pode se recuperar reproduzindo logs se você está usando um mecanismo transacional, mas às vezes você terá problemas mais sérios. Isso é tão verdadeiro com o DRBD quanto com outros armazenamentos de bloco compartilhado, como um volume SAN compartilhado ou arquivos de banco de dados (Heaven proíbe) no NFS.

Hipoteticamente, um banco de dados compatível com ACID deve sempre se recuperar normalmente de transações incompletas. Na prática, e especialmente com algumas versões do MySQL, isso nem sempre é o caso (em grande parte porque o MySQL não possui o maior legado de conformidade com o ACID, embora as coisas tenham melhorado nos últimos anos). Manter backups freqüentes é sempre uma coisa sensata a se fazer.

Não há como garantir que qualquer sistema de alta disponibilidade sempre continuará trabalhando em um failover. O melhor que você pode fazer é tomar as decisões certas ao arquitetar sua solução de HA e testá-las para validar suas suposições sobre como ela se comportará quando as coisas derem errado.

No seu caso, você pode querer considerar um escravo em espera caso encontre um problema de consistência no disco do mestre. É preciso trabalho manual para promovê-lo, é claro, mas pelo menos você não estará restaurando dados de horas ou dias.

    

Answer 2

Eu não acho que o DRBD seja a solução certa aqui.

Dependendo da sua carga de trabalho, você provavelmente quer uma ou uma combinação abaixo

• Replicação mestre-escravo
• Mestre - mestre
• Mestre - Mestre com escravos
• cluster MySQL

O primeiro é bastante trivial, o segundo tem algumas ressalvas, como Split Brain, STONITH (Atirar o Outro Nó na Cabeça), entre outros.

Este pode ser um tópico complexo e eu recomendo que você pesquise e teste em profundidade para o uso pretendido. Existem muitos guias para cada um deles.

    

Answer 3

Se você tiver controle sobre o código do aplicativo, poderá usar a replicação síncrona do MySQL Galera em vez do DRBD. Galera tem o requisito de número ímpar de membros do nó do cluster, de preferência, pelo menos, três votos de voto da maioria que foi dados corretos. Você pode aumentar o MySQL Galera com HAProxy Portanto, em cada tijolo da web você executa o HAProxy, que então se conecta e verifica se os servidores MySQL estão ativos.

Aqui estão algumas das limitações link

    

Answer 4

Se você

• Executa o DRBD no modo síncrono (acho que o modo C?)
• Use o STONITH (esgrima para que, quando o DRBD eleger um nó, ele possa desligar o outro nó por meio de um mecanismo 'fora dos limites'.) Isso garante que só haverá um 'mestre' possível.
• verifique se suas unidades / controlador RAID não estão mentindo sobre gravar no disco. (Ou eles têm cache apropriado suportado por bateria)
• teste completamente todos os modos de falha. (Energia, rede, comando de administrador burro, aplicativo burro)

Depois, você pode ter certeza de que seu banco de dados está altamente disponível. No seu exemplo, se ele falhar no meio da transação, ele será abortado e seu aplicativo deve tentar novamente e provavelmente poderá conectar-se ao seu segundo nó, o que deve ter uma cópia consistente dos dados (porque todas as gravações são sincronizadas escrito para ambos os nós antes de retornar ao banco de dados que foi escrito).

    

Answer 5

Eu tentei o DRBD há alguns anos, mas tive muitos problemas após um failover.

Eu removi o DRBD da imagem movendo todos os dados & registra em uma matriz de unidades separada conectada por meio de controladores SAS duplos. Nós usamos um IBM DS-3525 para isso. O que é bom nessa configuração é que o sistema secundário está sempre conectado, simplesmente não tem a partição montada. Eu usei o Corosync para controlar o failover. Quando o primário retorna, o Corosync encerra o MySQL, desmonta as partições, as remete no mestre, inicia o backup do MySQL. Mesmo se a máquina mestre morresse no meio de uma transação, o InnoDB se recuperaria.

As matrizes de unidade geram cerca de US $ 15 a 20 mil nesse intervalo. Se você levar em conta que precisa de 2 de tudo (para não mencionar que precisa de hardware equivalente por nó), os custos de uma matriz são bem justificados. Outro benefício de um Drive Array é a velocidade. No meu caso, eu uso os drivers Multi-path para que os sistemas possam usar os dois controladores ao mesmo tempo. O rendimento comparado a um ataque interno é geralmente muito maior.

Christian mencionou Galera. Confira o Cluster Percona. Ele usa o Galera e é uma adição muito promissora para aumentar o nível de confiabilidade do MySQL.