Início / dba / Perguntas / 139459
Accepted
Rathish Kumar B
Asked: 2016-05-25 23:00:27 +0800 CST

Registro binário do MySQL - operação de gravação

  • 772

Considere um cenário, onde você tem um servidor MySQL master e slave em replicação. Como sabemos, log binário ativado no mestre e o escravo lê o log binário do mestre. Pela documentação do MySQL, entendo que apenas a transação totalmente confirmada será gravada no log binário , portanto, não há chance de perder nenhuma transação na replicação (se tudo funcionar bem). Portanto, minha suposição é que, assim que a transação for concluída e gravada no tablespace, ela será gravada no log binário.

Minha dúvida é se a operação de gravação do log binário é concorrente ou sequencial? Isso significa, por exemplo, antes de gravar no log binário e depois de gravar no tablespace, se o servidor for desligado ou travar, o que acontecerá com as transações que ocorreram nesse meio tempo?

Além disso, estou usando mysqlbinlogutilitário e definido com stop-neverparâmetro. Eu preciso saber, quando stop-neverhabilitado, o log binário estará sincronizado no servidor de destino (eu testei com flush logs - ele também cria um novo log no destino).

PERGUNTAS

  1. Como funciona a cópia do log binário?
  2. É a primeira gravação no log binário mestre e copiada no log de destino?
  3. Ele está gravando no log binário de origem e destino simultaneamente?
  4. Qual será o impacto do desempenho do MySQL e do desempenho de E/S do disco?

Se eu entendi mal o conceito, gentilmente me corrija. Desde já, obrigado.

mysql replication

1 respostas

  1. Best Answer

    Aqui estão as respostas para cada uma das suas perguntas

    1 Como funciona a cópia do log binário?

    Escrevi uma lista detalhada das etapas executadas pela replicação do MySQL em minha resposta a A replicação do MySQL é afetada por uma interconexão de alta latência? .

    Alguém respondeu a mesma postagem , mas do ponto de vista do DB Client

    2 É a primeira gravação no log binário mestre e copiada no log de destino?

    Existem muitos passos intermediários

    • O mestre conclui uma atualização SQL (atualização única ou grupo de atualizações (confirmação de grupo AKA))
    • O mestre grava um dos seguintes em seu log binário
    • IO Thread do Slave copia o SQL Update do log binário do Master para seus relay logs
    • O SQL Thread no escravo lê atualizações de seu log de retransmissão e processos. Se log_slave_updates estiver habilitado, então o Slave grava aquele comando SQL em seu log binário local.

    3 Ele está gravando no log binário de origem e destino simultaneamente?

    Nunca. Não com replicação semisync, nem com replicação GTID. Basta olhar para as etapas acima

    4 Qual será o impacto do desempenho do MySQL e do desempenho de E/S do disco?

    Isso depende de onde os logs binários e logs de retransmissão são armazenados. Se os dados e logs estiverem na mesma montagem de disco, você fará gravações aleatórias de dados e gravações sequenciais de logs. Ambos estarão competindo pelo mesmo espaço em disco. Você deve separá-los (Veja minha postagem do ano passado. O log Redo em um servidor MySQL de produção deve ser configurado para outro local? )

    • 0

relate perguntas