mk-table-sync em um cenário mestre-escravo: Alterações não replicadas para o escravo

Question

Eu tenho usado o mk-table-sync para sincronizar tabelas de um mestre para escravo no mysql 5.1. Infelizmente, enquanto diferenças são corretamente detectadas, modificações feitas no mestre (DELETE, REPLACE, ecc.) não parece ser propagado para o escravo. SHOW SLAVE STATUS não revela problemas de conexão.

Basicamente, fazendo

mk-table-sync -v  --execute --databases=forum --sync-to-master 
h=localhost,D=forum,t=user
# Syncing D=forum,h=localhost,t=user
# DELETE REPLACE INSERT UPDATE ALGORITHM START    END      EXIT DATABASE.TABLE
#      0       7      0      0 Chunk     14:35:00 14:35:01 2    forum.user

repetidamente dá sempre os mesmos resultados, sem uma mudança real para o escravo.

Faça o login no escravo:

link

Faça o login no master:

link

O mesmo vale para as DELETEs feitas no mestre e para todas as outras tabelas no banco de dados replicado.

Alguma idéia?

Obrigado antecipadamente

    

Answer 1

Honestamente, nunca confiei no parâmetro --execute para o mk-table-sync. Eu sempre uso --print em vez disso.

Substitua isto

mk-table-sync -v  --execute --databases=forum --sync-to-master h=localhost,D=forum,t=user 

com isto se você tiver o log binário ativado

echo "SET SQL_LOG_BIN=0;" > DBChanges.sql
mk-table-sync -v  --print --databases=forum --sync-to-master h=localhost,D=forum,t=user >> DBChanges.sql

ou isto se o escravo não tiver registro binário

mk-table-sync -v  --print --databases=forum --sync-to-master h=localhost,D=forum,t=user > DBChanges.sql

Dessa forma, você pode ver o SQL real para rodar com segurança no slave.

ATUALIZAÇÃO 2011-05-31 12:57

"Interessante. Corrija-me se estiver errado, mas as consultas executadas no mestre não devem ser propagadas para o escravo por meio da replicação? Não entendo bem por que isso não acontece"

Essa é uma pergunta justa. No entanto, pense na maneira como o MySQL Replication funciona. Quando uma instrução SQL é concluída em um mestre, ela é registrada nos logs binários do mestre. O encadeamento de E / S do escravo lê qualquer nova entrada nos registros binários do mestre e os anexa ao último dos registros de retransmissão do escravo. O encadeamento SQL do escravo lê as entradas do log de retransmissão como uma fila FIFO e processa as instruções SQL na ordem de sua gravação. Se o escravo tiver log-slave-updates e log-bin em sua configuração, a declaração SQL após a conclusão será registrada nos logs binários do escravo.

Chega de conversa fiada sobre a replicação do MySQL.

Agora, por que um mestre não replicaria para um escravo ???

Aqui estão algumas possibilidades para você explorar:

POSSIBILIDADE # 1 : latência da rede fazendo com que as entradas do log binário do mestre não sejam propagadas para os logs de retransmissão do escravo em tempo hábil ou não.

POSSIBILIDADE # 2 : pacotes do MySQL são muito pequenos e erros sendo ignorados. Isso pode acontecer somente no seguinte cenário: O max_allowed_packet no mestre é maior que o max_allowed_packet no escravo. Isso normalmente impediria a replicação de frio em seus rastros. Se você está pulando todos os erros de escravo (se você tiver slave-skip-errors = all em /etc/my.cnf) então vários tipos de dados normais podem ser ignorados neste cenário único.

POSSIBILIDADE # 3 : Config para pular qualquer erro de chave duplicado no thread SQL do escravo

[mysqld]
slave-skip-errors=1062 (skips duplicate key errors)

POSSIBILIDADE # 4 : Config para pular qualquer erro de SQL no thread SQL do escravo

[mysqld]
slave-skip-errors=all (skips every SQL error under the sun)

POSSIBILIDADE # 5 : Ter o encadeamento de E / S do escravo simplesmente morrer sem dizer ao mysqld . Isso pode acontecer. Correção simples? Faça o seguinte para restabelecer o encadeamento de E / S escravo:

STOP SLAVE IO_THREAD;
START SLAVE IO_THREAD;

POSSIBILIDADE # 6 : Tendo uma combinação errada de replicate-do-db e replicate-ignore-db em /etc/my.cnf (Aviso: Esta é estritamente minha opinião)

Alguns misturam ambas as opções em /etc/my.cnf e não acham nada disso. IMHO, essas opções devem ser mutuamente exclusivas. Você segue a lógica de filtrar dados ou filtrar dados em um escravo. Eles não devem ser usados juntos, pois você pode obter resultados espúrios da replicação. Os dados devem estar lá ou não, os dados NÃO devem estar lá e não .

    

Answer 2

É possível que você esteja usando uma versão do mk-table-sync que não configura o formato binlog para STATEMENT, portanto, não está realmente alterando nenhum dado no master (como projetado) e, portanto, nada entra no log binário .