A replicação multi-nível do MySQL quebra constantemente

Question

Eu tenho a configuração de replicação da seguinte forma

Master A ----> Slave B ------> Slave C
     \-------> Slave D
      \------> Slave E - H

Eu uso esta configuração porque eu preciso de uma cópia local no servidor do escritório (ou seja, o escravo C). Eu não quero sobrecarregar o Mestre A porque ele já está recebendo todas as inserções e carga extra das conexões dos escravos.

Então eu configurei a replicação multi-nível. Mestre A replica para Slave B, que por sua vez é mestre em Slave C.

Replicação de A - > B funciona perfeitamente. Replicação de B - > C quebra constantemente com erros de "chave duplicada". Eu tenho o log de relay ativado no servidor B para ativar a replicação de B para C.

Alguém já encontrou esse problema antes?

Master / Slave B my.cnf é o seguinte:

# Replication setup
log-bin=/var/log/mysql/mysql-bin
server-id=2
sync_binlog=0
binlog_format=mixed
log-slave-updates
replicate-same-server-id = 0
expire_logs_days=15

Existe alguma coisa que estou fazendo errado?

    

Answer 1

Se você está recebendo erros de chave duplicados, então algo está gravando no escravo C (provável) ou você está executando operações de inserção / atualização não-determinísticas no mestre que não são replicadas bem no formato MIXED (improvável). Ter sync_binlog = 0 conjunto pode causar alguns problemas para você, mas eles provavelmente seriam raros e ocorreriam apenas em torno de falhas do servidor. Se forem verdadeiras consultas não-determinísticas causando um problema, você pode querer considerar binlog_format = ROW.

Independentemente disso, primeiro você precisa lidar com a sincronização dos dados. A maneira mais simples de fazer isso é apenas começar com um novo backup de B e certifique-se de MUDAR MESTRE PARA as coordenadas de registro binário corretas. Se uma restauração de um backup estiver fora de questão, você poderá investigar usando uma ferramenta como o mk-table-sync do maatkit.org. É uma ferramenta complicada, e se você não estiver lidando com TBs de dados, eu usaria um backup recente.

Em seguida, verifique se C está definido como read_only em my.cnf com e com

[mysqld]
read_only

e também executam isso no servidor

SET GLOBAL read_only=1;

No entanto, lembre-se de que read_only não se aplica a usuários com o privilégio SUPER, portanto, certifique-se de que ninguém, exceto o usuário root, tenha acesso e esteja usando usuários sem privilégios para consultar o banco de dados.

Honestamente, com apenas 7 escravos, eu ignoraria a complexidade da configuração de várias camadas e manteria tudo em um único nível. A sobrecarga por escravo não é cara, a menos que você esteja lidando com uma conexão de rede muito lenta no mestre. Você tem evidências de que o streaming de logs binários para escravos está causando uma degradação no desempenho?

    

Answer 2

Eu segundo o read_only nos escravos. É uma verificação de sanidade, se nada mais. Tem certeza de que os server_ids são todos diferentes? Mostrar o erro de chave duplicado real também pode ajudar (se puder). Poderia haver algum gatilho perdido em C ou B que? Investigue a tabela que está gerando os erros. Quantos bancos de dados estão no servidor mestre? Todos eles são replicados?