Como tornar a replicação do MySQL confiável?

OBSERVAÇÃO #1

Você mencionou que os desenvolvedores do Ask colocam todas as tabelas temporárias em um banco de dados separado

Se seus desenvolvedores estiverem usando comandos CREATE TEMPORARY TABLE para criar tabelas temporárias, eles precisarão usar CREATE TABLE. Aqui está o porquê:

Com o MySQL Replication processando uma tabela temporária, é isso que ocorre

• 1) Corrida principalCREATE TEMPORARY TABLE
• 2) Comando inserido no log binário
• 3) A replicação copia isso para os logs de retransmissão do escravo via I/O Thread
• 4) Execuções de Thread SQL EscravoCREATE TEMPORARY TABLE
• 5) Escravo processa dados com essa tabela temporária

De vez em quando, alguém pode STOP SLAVE;executar um backup. Se STOP SLAVE;for emitido logo após a etapa 4, a temperatura criada desaparece e seus dados também. Quando você executa START SLAVE;quebras de replicação reclamando instantaneamente que a tabela não existe. Isso é normal porque quando uma conexão de banco de dados termina deliberadamente ou acidentalmente, todas as tabelas temporárias abertas CREATE TEMPORARY TABLEna sessão de banco de dados são descartadas. Executando STOP SLAVE;kill do thread SQL que estava segurando a abertura da tabela temporária.

A única solução para isso é criar a tabela usando CREATE TABLEem vez de CREATE TEMPORARY TABLE. Quando executado STOP SLAVE;, a tabela temporária que você criou normalmente não desaparece.

Eu vi isso acontecer talvez 10 vezes em minha carreira de DBA. Consertá-lo usando os logs binários para descobrir o nome das tabelas temporárias, para criar essas tabelas usando CREATE TABLE, então iniciar a replicação foi a única manutenção possível sem apenas força bruta copiando o mestre.

OBSERVAÇÃO #2

mk-table-syncsó funciona em tabelas com chaves primárias e/ou chaves únicas. Funciona talvez 99% do tempo. Já vi casos em que a soma de verificação de uma tabela no mestre e no escravo eram diferentes. Eu rodaria mk-table-sync, ainda havia diferenças (Claro, eu estava fazendo mk-table-syncem replicação circular com 3 masters, o que pode ser um pouco perigoso. Usar em Master/Slave é bem mais estável)

OBSERVAÇÃO #3

Você mencionou que existem algumas consultas inseguras. Ele apresenta alguns problemas com a replicação baseada em MIXED?

Depende. A consulta insegura mais popular é qualquer UPDATE ou DELETE que usa ORDER BY ... LIMIT. Com o SBR, isso pode fazer com que o MySQL atualize ou exclua linhas de uma tabela no escravo em uma ordem diferente da do mestre. Com RBR, acredito que as mudanças exatas em uma linha são mais identificáveis ​​para UPDATE ou DELETE no Slave.

SOLUÇÃO : Evite usar consultas inseguras. Então, você não vai se preocupar !!!

OBSERVAÇÃO #4

Acabei de ler seu segundo link. ROF!!! Estou familiarizado com o pôster da resposta.