O que impede loops nas configurações do master-master do mysql?

1

Eu tenho dois servidores executando o mysql como dual master (cada servidor é um mestre, cada servidor é escravo para o outro). Ao solucionar um possível problema durante o pico de carga, comecei a me perguntar como o mysql impede um "loop" de comandos em um relacionamento como esse.

Minha pergunta específica é:

If A is slaved to B, and B is slaved to A, what prevents an SQL command which is executed on A, and which propagates to B via their master(A)->slave(B) relationship, from being further propagated back to A via the master(B)->slave(A) relationship?

Meu palpite é que além dos comandos em si há algum tipo de único identificado para o comando passado de tal forma que A sabe que executou o comando anteriormente (presumivelmente usando a opção server-id ). No entanto, meu google-fu é muito fraco hoje para descobrir como isso funciona embaixo das capas.

Veja como isso está relacionado ao meu problema. A cada 5 minutos, vejo um atraso entre Read_Master_Log_Pos e Exec_Master_Log_Pos . Eu entendo a causa básica disso - eu acredito que o aplicativo está configurado para despejar uma tonelada de dados no banco de dados em intervalos de cinco minutos (na verdade, no gráfico dos deltas de 15 segundos entre os valores, eu suponho que há um número constante de corredores a cada 5 minutos, com mais de 15 em 15 minutos e mais ainda a cada 30 minutos).

Minha real preocupação é que ambos os escravos mostrem o mesmo atraso. Meu entendimento do design deste aplicativo é que o servidor de banco de dados "ativo" (da perspectiva do aplicativo, não de uma perspectiva mysql) sempre seria usado, a menos que o servidor estivesse indisponível, caso em que o aplicativo tentaria usar o banco de dados "em espera" servidor. Se isso é verdade, por que estou vendo o atraso de leitura / execução em ambos os escravos? Se não for verdade, ou eu tenho um mal-entendido fundamental da arquitetura do aplicativo, ou o servidor "ativo" está se tornando superutilizado a ponto de o aplicativo estar falhando, mesmo que o servidor nunca esteja "inativo"? (essas duas últimas não são perguntas do SF, apenas perguntas que estou trabalhando para responder)

Eu li que o mestre em um relacionamento mysql mestre / escravo é bastante simples, pois envia tudo para seus escravos e cabe aos escravos decidir quais comandos, se houver, executar. Se for esse o caso, talvez o atraso que estou vendo no escravo para o servidor em espera seja causado por todos os comandos já executados sendo baixados e tendo que ser avaliado se esse comando já foi executado.

    
por jj33 17.08.2009 / 20:40

2 respostas

12

No que diz respeito à sua pergunta específica, é uma combinação de duas coisas:

  1. Por padrão, se um servidor receber uma instrução por meio de replicação, ela não enviará a mesma declaração para seus escravos, evitando qualquer tipo de loop. Esta configuração, no entanto, pode ser alterada (adicionando ' log-slave-updates ' ao my.cnf), levando a:
  2. Na replicação, ele envia o server-id do servidor de origem junto com a instrução. Se um servidor receber uma instrução via replicação com o mesmo id de servidor, ele não irá executá-lo, impedindo-o de executar a mesma instrução duas vezes.
por 17.08.2009 / 20:50
1

Usar o mysql-master-master só é realmente seguro no caso geral se

  • Você só escreve para um servidor de cada vez
  • Quando você passa da gravação para um servidor para o outro, espera que a replicação termine de recuperar antecipadamente

Se você puder ter certeza disso, tudo bem.

Se seu aplicativo é MUITO cuidadosamente escrito para levar em conta o fato de que ele está sendo executado no mysql-master-master (Por exemplo, tenha muito cuidado com índices exclusivos - certifique-se de não ter uma violação de chave no outro servidor então você provavelmente está bem. Eu não consegui escrever facilmente esse aplicativo.

É claro que o mysql-master-master não é útil para melhorar o desempenho de gravação, já que ambos os servidores precisam fazer todas as gravações também.

    
por 15.10.2009 / 22:35