Qual a velocidade da replicação do MySQL?

Estou pensando em configurar a replicação do nosso banco de dados mysql para poder ter escravos locais em cada uma de nossas filiais, e ter o mestre no escritório principal para melhorar o desempenho do aplicativo (significativamente) em nossas filiais.

O db em si não é tão grande (<1gb), mas eu estou pensando; considerando 200-300 atualizações de registros / min tops: qual a rapidez da replicação? (supondo, primeiro, uma conexão dsl genérica de 5 MB, mais rápida, se necessário - tentando manter os custos o mais baixo possível, mas o dinheiro está disponível para mais)

As tabelas inteiras são replicadas em lotes? A replicação é feita sob demanda, à medida que cada registro em uma tabela é atualizado (dos documentos, acho que estou vendo que é configurável)?

Notas:

• Estou pensando em 1 mestre, 2 escravos (2 filiais no momento) configurados como nos documentos aqui, exceto que é um aplicativo, não um cliente da Web
• Qualquer atualização feita no mestre precisa ser replicada para os outros escravos em <10 minutos.
• Tudo isso pressupõe que eu possa deixar nosso ORM (DevExpress XPO) satisfeito com o conceito de ler do escravo e escrever para o mestre.

A replicação do MySQL acontece o mais próximo possível do tempo real, limitado pela E / S do disco e da rede. Os escravos abrem uma tomada para o mestre, que é mantido aberto. Quando uma transação ocorre no mestre, ela é registrada no binlog e é simplesmente reproduzida no (s) escravo (s). Se o soquete entre mestre e escravo for interrompido, o binlog será repetido para o escravo na próxima conexão bem-sucedida.

A replicação multimestre faz a mesma coisa, mas nas duas direções.

Alguns cálculos básicos ajudarão você a determinar melhor suas necessidades de largura de banda.

Average transaction size * number of slaves * updates/minute = bandwidth needed

Espero que isto ajude.

A replicação no lado dos escravos é tratada por dois encadeamentos independentes.

• O processo do leitor de log, que se conecta ao mestre, recebe cada instrução de modificação de dados e a grava no log de retransmissão.
• O processo sql writer, que obtém novos itens do log de retransmissão, confirma as instruções no banco de dados de escravos e move o ponteiro escravo além dessa declaração para indicar o recebimento da consulta.

A latência de replicação é limitada pelo IO, primeiro o IO no banco de dados escravo para aplicar as transações do log de retransmissão (que pode envolver consultas SQL complexas) e, em segundo lugar, o IO no mestre para ler seu binlog e transmiti-lo a cada escravo.

A replicação do MySQL aumenta a capacidade de consulta de leitura, mas não aumenta o desempenho de gravação da consulta, que é bloqueado na velocidade que as entradas / saídas podem ser liberadas no binlog no mestre e no escravo

A replicação no MySQL é muito rápida para obter os dados para o escravo (mais rápido do que você poderá executar o UPDATEno mestre e alternar para outra janela para executar um SELECTno escravo, se(e somente se) as conexões de rede estiverem ativadas e tudo estiver funcionando corretamente. Qualquer conexão de classe DSL deve ser adequada para o caso geral de suas pequenas consultas regulares, mas grandes consultas de inserção / atualização podem demorar um pouco para serem copiadas e ressincronizadas no caso de um material de replicação (e o MySQL é cruelmente propenso a infelizmente, isso levará um tempo (copiando todo o banco de dados do mestre novamente). Existem truques para limitar o impacto da ressincronização no seu mestre, como colocar o MySQL no LVM para que você possa fazer um bloqueio / captura instantânea muito rápido e sincronizar o conteúdo da captura instantânea com o escravo, mas, em última análise, uma ressincronização será uma droga.