Este é o segundo post de uma seria que aborda as limitações do MySQL em determinadas circustancias (veja a parte 1).

O log binário é necessário não somente quando falamos em replicação, mas também para um ponto de recuperação. Considerando um cópia de segurança bem como a posição do log binário correspondente , você pode repetir utilizando o roll-forward e o estado do seu servidor para o ponto desejado.

Devemos levar em consideração que o log binário reduz significativamente o desempenho do MySQL. O problema não se encontra no registro em si, pois escrever o log não é um grande trabalho. O que é realmente difícil e caro é manter a consistência e a durabilidade, e o Rubor que é adicionado no disco a cada chamada fsync para garantir a transação.

O servidor realiza uma transação do tipo XA entre o InnoDb e o log binário, este procedimento adiciona mais chamadas fsync, e gera uma disputa do tipo mutex.


A redução de desempenho pode ser uma ordem de magnitude.


Qual a solução? Não existe uma forma concisa de resumir, pois existe um nível considerável de complexidade, e sinceramente não possuo acesso suficiente a grandes servidores que me permitam fazer uma analise mais profunda. O log binário e o código de replicação e sua interação com o InnoDB é um pouco difícil de entender. Kristian Nielson possui uma serie de posts sobre o assunto.

Acredito que uma correção completa deve exigir mudanças bastante significativas no que se refere a arquitetura MySQL, isso será complexo e bastante difícil de ser feito. Para fazer uma replicação através do log de transações InnoDB funcionaria se:

  • Todos os dados estivessem em InnoDB.
  • Os dados do InnoDB não têm que ser sincronizados com os arquivos, Frm e Drizzle se livrando do frm e hooray.
  • As prerrogativas e outras alterações para os dados não-InnoDB no MySQL feitos manualmente.

Poderia até funcionar se você não alterar os privilégios ou esquema, mas isso é uma descrição de um sistema de replicação bastante limitado, do ponto de vista do usuário, ainda assim devemos considerar.

Não existiria necessidade de ser um mecanismo de transporte de arquivos de log e InnoDB, colocado em um estado constante de ‘recuperação’, tendo que ser modificado para estar disponível no modo somente leitura, desta forma realizando consultas e leituras. Isto pode ser feito é apenas uma questão de querer vencer as dificuldades.

É interessante notar que o PBXT faz a replicação através de seus logs de transação, então não há precedente para isto entre mecanismos de armazenamento MySQL. E não há tecnologia de sincronização multi-master.