Retardo de replicação do mestre-mestre do MySQL

Question

Configurei dois servidores MySQL ( MySQL-1 , MySQL-2 ) na replicação master-master no mesmo datacenter usando uma conexão de backend local com as seguintes opções:

innodb_flush_log_at_trx_commit=1
sync_binlog=1

Usamos um balanceador de carga para arredondar as solicitações do MySQL de um lado para o outro igualmente entre os dois servidores MySQL. Isso funciona muito bem, mas estou preocupado com o atraso de replicação. Por exemplo, se o usuário A inserir uma linha no MySQL-1, o usuário A seleciona do MySQL-2, os dados podem não ter sido replicados com sucesso.

Basicamente, minha pergunta é, quanto atraso deve ser esperado (milissegundos, segundos)? São mais suas opções do MySQL para definir como evitar / reduzir o atraso?

    

Answer 1

Isso depende do desempenho de seus servidores, que está relacionado a quantas consultas cada servidor precisa processar, o tamanho de suas tabelas e assim por diante. Usar essa solução de replicação deve ser síncrona, o que definitivamente irá impor algum atraso durante as transações. Isto é simplesmente porque cada transação não deve ser considerada completamente comprometida, a menos que seja feita em ambos os nós.

Acho que uma opção mais segura é equilibrar as solicitações com base no IP de origem do cliente (se isso for possível / suportado). Nesse caso, todas as solicitações provenientes do mesmo cliente serão encaminhadas para o mesmo servidor de banco de dados.

    

Answer 2

Eu encontrei exatamente esse problema com um mestre - > muitas configurações escravas. Foi ainda pior do que a sua situação porque as leituras eram garantidas pelo escravo, em vez de ter uma chance de 50%.

Toda vez que um usuário escreve para o banco de dados (como uma postagem no fórum ou clica em um botão "curtir"), ele recebe um redirecionamento HTTP para a página que deve exibir sua postagem, mas > nunca fez. O tempo de ida e volta do redirecionamento e a solicitação de acompanhamento foram menores que o atraso de replicação.

Assistir ao atraso com SHOW SLAVE STATUS mostrou que quase sempre era menor que um segundo. Ele ficou mais alto do que ocasionalmente, no entanto. Como o SQL de replicação é de encadeamento único, uma consulta lenta de 10 segundos causará um atraso de 10 segundos na sua replicação.

A solução para nós acabou sendo modificar todas as nossas páginas "postadas" para sempre lerem o mestre em vez de um escravo. No seu caso, certificar-se de que cada servidor da Web saiba qual banco de dados o pedido anterior escreveu será difícil.

Uma solução melhor pode ser inserir dados gravados recentemente em uma instância do memcached. Mesmo que seus dados do memcached tenham um tempo de expiração de 10 segundos, isso deve ser suficiente para cobrir o atraso de replicação.

    

Answer 3

O desfasamento depende primário de:

1. o número de operações de gravação (inserção e atualização)
2. hardware (velocidade do disco e cpu)
3. carga do servidor (selecione)

É impossível calcular o atraso antes. Posso sugerir fazer alguns testes intensivos (para você) com operações de gravação e leitura simultâneas.