Em uma configuração de replicação de hospedagem MySQL, o parâmetro Seconds_Behind_Master (SBM), conforme exibido pelo comando SHOW SLAVE STATUS, é comumente usado como uma indicação do atraso de replicação atual do escravo . Nesta postagem do blog, examinamos como entender e interpretar esse valor em várias situações.
Valores possíveis de segundos atrás do mestre
O valor de SBM, conforme explicado na documentação do MySQL, depende do estado do MySQL slave em geral e dos estados do MySQL slave SQL_THREAD e IO_THREAD em particular. Enquanto IO_THREAD se conecta com o mestre e lê as atualizações, SQL_THREAD aplica essas atualizações no escravo. Vamos examinar os possíveis valores de SBM durante diferentes estados do MySQL Slave.
Quando o valor SBM é nulo
- SBM é sempre NULL se seu slave estiver parado ou seu thread SQL estiver parado (ou não estiver em execução).
- SBM também será NULL se o IO Thread for interrompido, desde que o SQL Thread já tenha processado todos os eventos do log de retransmissão. Um exemplo de saída de SHOW SLAVE STATUS (recortado para mostrar apenas os valores de interesse) demonstra isso:
Slave_IO_State:
Master_Host:172.19.0.13
Slave_IO_Running:Não
Slave_SQL_Running:Sim
Seconds_Behind_Master:NULL
Master_UUID:23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State:O escravo leu todo o log de retransmissão; aguardando mais atualizações
Retrieved_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Executed_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213
Quando o valor SBM é zero ou positivo
- O SBM refletirá um valor válido (>=0) quando o SQL Thread estiver processando eventos ativamente. Isso é verdade independentemente do estado do thread de E/S. Por exemplo:
Slave_IO_State:
Master_Host:172.19.0.13
Slave_IO_Running:Não
Slave_SQL_Running:Sim
Seconds_Behind_Master:3399
Master_UUID:23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State:Aguardando os trabalhadores escravos processarem suas filas
Retrieved_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Executed_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:1-118774
No exemplo acima, podemos ver que o escravo está atrás do mestre comparando o Retrieved_GTID_Set e o Executed_GTID_Set. Nesses casos, Seconds_Behind_Master representará a diferença entre o timestamp da última transação processada pelo SQL Thread e o timestamp da mesma transação quando foi processada no master. Esse registro de data e hora da transação do mestre é preservado por meio de replicação e, portanto, o escravo poderá calcular o SBM localmente.
Além disso, uma vez que o escravo alcança todos os logs de retransmissão (ou seja, o GTID executado se torna 23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213/), Seconds_Behind_Master será gire para '0' se o IO Thread estiver em execução, ou para 'NULL' se o IO Thread não estiver em execução.
Tutorial #MySQL – Entendendo os segundos por trás do valor mestreClique para tweetar
Compreendendo a velocidade de execução do MySQL Slave
Supondo que o SQL Thread e o IO Thread no escravo estejam em estados de execução, é possível entender as velocidades de execução relativas do mestre e do escravo monitorando o valor SBM. Um valor consistente de '0' ou um valor constante indica que o escravo está executando na mesma velocidade que o mestre. Por outro lado, uma inclinação ascendente para Seconds_Behind_Master indica que o escravo está executando mais lentamente que o mestre.
O Console de Monitoramento do ScaleGrid para MySQL no Azure plota os valores de SBM ao longo do tempo para os nós escravos.
Valor zero ou constante de SBM
No exemplo acima, o escravo foi iniciado cerca de 40 horas após o mestre ter gravações ativas. Uma vez iniciado, o escravo começou a replicar esses dados, e vemos que o SBM estava bastante plano, indicando que o escravo executou na mesma velocidade que o mestre. Observe também que a queda do SBM para '0' é acentuada, o que realmente significa que, embora a última transação que o escravo executou tenha sido executada cerca de 40 horas antes no mestre, uma vez que alcançamos, há um atraso de '0'.
Valores crescentes de SBM
No gráfico abaixo, podemos ver que o SBM está aumentando constantemente, o que significa que a velocidade de execução do escravo é menor em comparação com a do mestre. Este é realmente um caso em que estamos executando 20 threads fazendo gravações contínuas no mestre e um escravo de thread único não é capaz de acompanhá-lo.
Por fim, é importante observar que, em nossas discussões até agora, não assumimos nenhum gargalo de rede. No caso de redes lentas, o próprio IO Thread escravo estará atrasado em relação ao mestre e, se o SQL Thread for rápido o suficiente, o SBM oscilará entre '0' e um número positivo. Nesses casos, o SBM não será um parâmetro útil para entender o real atraso com o mestre.
Se você gostou desta postagem do blog, confira nossos outros tutoriais populares de gerenciamento de banco de dados MySQL para saber mais sobre como otimizar suas implantações:
- Calculando o tamanho do pool de buffers InnoDB para seu servidor MySQL
- Tutorial MySQL – Configurando e gerenciando SSL em seu servidor MySQL
- Explicação da estrutura de alta disponibilidade do MySQL – Parte I:introdução
