Começar com...
http://yoshinorimatsunobu.blogspot.com/2009 /08/grande-desempenho-efeito-de-fixação.html
Antes do Plugin InnoDB 1.0.4, era assim:
obtain mutex
write innodb log and fsync, for prepare-phase (skip if innodb_support_xa=0)
write binlog (fsync as appropriate if sync_binlog > 0)
write innodb log and fsync, for commit-phase
release mutex
Em e após o Plugin InnoDB 1.0.4 (e MySQL 5.5), agora é:
write innodb log and fsync, for prepare-phase (skip if innodb_support_xa=0)
obtain mutex
write binlog (fsync as appropriate if sync_binlog > 0)
write innodb log, for commit-phase
release mutex
fsync innodb log, for commit-phase
Como você pode ver, na nova versão, nada (exceto no caso de
sync_binlog> 0) é fsync'd na seção crítica. Dessa forma, a confirmação de grupo agora funciona e garante uma taxa de transferência simultânea muito melhor. Por exemplo, com a versão anterior "quebrada", se você tivesse 100 threads de commits simultâneos, todos os fsyncs seriam serializados e você obteria 100 fsyncs para preparação e outros 100 fsyncs para commit. Portanto, o commit do grupo foi completamente quebrado.
Agora, com a implementação mais recente, os fsyncs são agrupados dependendo da simultaneidade das transações, garantindo a ordenação da operação entre o log innodb e o log binário. Isso também significa que se houver apenas um thread, não haverá ganho de desempenho.
Quanto à sua pergunta, quando ocorre uma falha após uma transação ser gravada no log binário, mas antes de ser gravada no log de transações - estou na mesma página que você.
Se o servidor travar antes da etapa final, há uma pequena chance de você ter uma discrepância entre o log innodb e o log binário (um pode estar à frente do outro), mas é garantido que você tem todas as informações sobre o que fazer examinar no log do innodb, conforme registrado na fase de preparação.
No entanto, o que fazer com o não comprometido ainda é indeterminístico. Por exemplo, a menos que
sync_binlog = 1 há uma chance de que um escravo tenha recebido os dados, mas ainda não tenha sincronizado totalmente o log binário no mestre. Você não pode simplesmente refazer a transação com falha, pois ela já pode ter sido executada em um dos escravos. O que também significa que o log binário pode ser menor que o log innodb, retornando "O log binário [nome_do_arquivo] é menor que o tamanho esperado". conforme descrito no documento oficial, e você precisa reconstruir o slave do zero. Não muito humano amigável.
http://dev.mysql.com/doc/refman /5.1/en/binary-log.html
Como a consistência em termos de ordenação de operação é garantida independentemente do
innodb_support_xa configuração (que contradiz o que é dito no documento oficial em innodb_support_xa , talvez porque foi escrito sobre o estoque innodb 5.0.3 muito antes da correção de simultaneidade), e a consistência entre o log innodb no mestre e o log de retransmissão no escravo não é estritamente garantida mesmo com innodb_support_xa , não vejo sentido em usar innodb_support_xa . É assustador não seguir a recomendação oficial, no entanto, parece obsoleto e errado em muitos pontos. Gostaria de saber se há alguma correlação entre o
innodb_flush_log_at_trx_commit configuração e o innodb_support_xa comportamento quando o primeiro é definido como 2 ou 0. Uma maneira prática de pensar é que o failover para o escravo é seguro - afinal, a transação com falha era algo que você queria que fosse feito - mas nunca faça failback para o mestre, pois pode haver alguma discrepância nos dados. Você precisa copiar totalmente os dados do escravo, antes de tornar o mestre um novo escravo. Em outras palavras, quando o mestre travar, confie no escravo a partir de então - dessa forma, você não precisa mexer no log innodb para recuperação de falhas.
Observe também que o MySQL 5.5 suporta replicação semi-síncrona, na mesma linha de "confiar no escravo" - pensei que você pudesse estar interessado.
http://dev.mysql.com/doc/refman /5.5/en/replication-semisync.html
