¿'Seconds_Behind_Master` muestra exacto esclavo de Master?

Question

Lo hace Seconds_Behind_Master ¿Siempre muestre el número correcto de segundos que el esclavo está detrás del maestro?

También he implementado el monitoreo de replicación MK-Heartbeat.

Mostraba el otro resultado en comparación con Seconds_Behind_Master.

¿Cuál es más preciso?

Answer 1

Seconds_behind_master se basa en la diferencia entre unix_timestamp () y la marca de tiempo registrada para la consulta dentro del registro binario del maestro, o el registro de retransmisión en el esclavo. Seconds_behind_master realmente te pierde en el contexto de tiempo real si la replicación procesa una serie de consultas de larga duración. El retraso podría crecer astronómicamente hasta que se procesen todas las entradas de registro de retransmisión y luego Seconds_Behind_Master de repente caiga a cero. En términos de tiempo real, no tiene forma de saber o anticipar cuándo el retraso se disipará eventualmente hasta que llegue a cero.

Usando estrictamente MySQL, puede monitorear el retraso de replicación en términos de tiempo real de la siguiente manera:

• De SHOW SLAVE STATUS\G, obtenga dos valores
  • Relay_Master_Log_File Representa el archivo de registro que contiene la última instrucción SQL ejecutando con éxito en el maestro que se ejecutó en el esclavo.
  • Exec_Master_Log_Pos representa la posición dentro Relay_Master_Log_File de la última declaración de ejecución exitosa de SQL en el maestro que se ejecutó en el esclavo.

Podrías realizar esto contra ese registro binario:

TMSTMP=`mysqlbinlog ---start-position=EMLP RMFL | head -50 | grep "^SET TIMESTAMP=" | head -1 | sed 's/=/ /g' | sed 's/\// /g' | awk '{print $3}'`
RIGHTNOW=`date +%s`
(( REPLAG = RIGHTNOW - TMSTMP ))

Donde EMLP está EXEC_MASTER_LOG_POS RMFL y es el relay_master_log_file

Si bien esta es de manera realista la forma correcta de obtener retraso de replicación utilizando solo el archivo de registro y la postición, debe

• comunicarse con el esclavo para obtener el archivo de registro y la posición necesarios
• comunicarse con el maestro para recuperar el vertedero del binlog
• Volcar el binlog cada vez que verifica (mySQLBInlog funciona de manera segura cuando no es el registro abierto actualmente, esto puede requerir realizar registros de descarga en el maestro antes de descargar el archivo de registro maestro)

Obtener retraso de replicación de los registros binarios usted mismo requiere mucho más trabajo en las piernas.

mk-heartbeat Comprueba una mesa de latidos y solo registra. Usar una mesa en vivo en un maestro y comparar la copia del esclavo de la tabla Heartbeat con unix_timestamp () en el esclavo es una medición de retraso en tiempo real mucho más concisa.

Deberías ir con MK-Heartbeat.