MySQL binlog limitações

Question

Eu tenho uma instância do MySQL em execução no AWS, com cerca de 5000 insere por segundo.Qualquer idéia do que o impacto de desempenho será que se eu usar binlog (linha) e uma binlog tailer?

Verifique este link

No meu entendimento, uma bandeja de log tailer controla o MySQL binlog periodicamente, a fim de fazer um 'tempo real' conexão de dados possível.O binlog tailer é executado em NodeJS.

O ponto é, eu tenho que usar o MySQL e eu quero usar o Meteor para obter os dados em tempo real para os meus clientes.Daí a minha ideia de usar esta binlog tailer.

Porque o banco de dados do MySQL vai ser preenchido intensivamente (5000 insere por segundo) , eu quero saber em que ponto do binlog/binlog tailer fica problemas graves de desempenho.

Grts, Tom

Answer 1

Eu tenho desenvolvido software com funcionalidade semelhante, a capacidade de usar a replicação do MySQL fluxo (log binário, binlog) para a captura de eventos em quase em tempo real, em resposta às inserções/atualizações/exclusões da base de dados.

Aqui estão algumas observações que fiz em relação ao desempenho.Felizmente, o potencial de hot spots são em grande parte independentes uns dos outros.

Vou assumir, pois eu não estava familiarizado com o Nó de pacote que você citou e só agora, dado o seu código a um exame superficial, que na verdade não são eles "rejeito" o binlog através de pesquisa, mas são, na verdade, emulando um escravo/servidor de réplica e ligar para o mestre e solicitando a replicação de fluxo.

O primeiro potencial gargalo é a capacidade do mestre para escrever a quantidade de Binlog dados necessários (e/S de taxa de transferência é a principal cobstraint).Se o seu mestre já está de registo em ROW formato e, em seguida, esse problema já está resolvido.Se não, em seguida ligue o Binlog formato, e ver.Eu preferem ROW o formato, de qualquer maneira, porque é muito útil para a recuperação de dados quando as consultas ir mal ou o aplicativo faz algo para os dados que ele não deveria ter.É possível (usando 3 ferramentas) para capturar o que aconteceu e o reverso -- na configuração padrão, quando uma exclusão ocorre (por exemplo) os dados excluídos, na verdade, é escrita no log binário.

O próximo ponto de consumo de recursos é o escravo conexão feita por uma ferramenta para o mestre, onde o mestre envia os dados.Um equívoco comum é que um escravo "pesquisa" o mestre.Na verdade, o escravo que inicia a conexão, mas o mestre envia os dados.Na verdade, é uma carga sobre o mestre que tem muito pouco impacto no desempenho quando o número de escravos conectados é pequeno (digamos, 5 ou menos).Essa carga pode ser eliminado do mestre inteiramente conectando-se a "binlog tailer de" não para o mestre, mas para um escravo do mestre, com log_slave_updates configurado.

O transporte dos dados do mestre para o pseudo-escravo pode comer significativa de largura de banda da rede, para que o seu utilitário externo deve apoiar o cliente/servidor do MySQL protocolo de compressão para reduzir essa largura de banda.Activar esta capacidade pode atingir taxas de compressão de 10:1, dependendo da carga.

O final, ponto de dificuldade é o utilitário externo em si.O MySQL Binlog tem um formato muito bem embalado formato binário (daí "log binário") que devem ser analisados e decodificado.A eficiência com que o utilitário externo pode descompactar e manipular este fluxo de dados irá determinar quão perto em tempo real os eventos detectados podem ser emitidas, desde ineficiente código fará com que seu decidiu o fluxo de eventos de ficar para mais e mais longe do mestre, embora este fator não terá qualquer impacto no desempenho do servidor mestre de si mesmo.

Em suma, se o mestre pode lidar com a carga de trabalho de geração de linha de formato binlogs para o volume de tráfego previsto, o resto do potencial questões ainda são problemas em potencial, mas eles devem não têm significativas implicações de desempenho no servidor mestre, em si.