Autor: Li Bin
Miembro del equipo de DBA de Acson, responsable del manejo diario de problemas del proyecto y la solución de problemas de la plataforma de la empresa. Hay más de 100 millones de hobbies, guitarra, viajar, jugar...
Fuente de este artículo: contribución original
* Producido por la comunidad de código abierto de Aikesheng, el contenido original no puede usarse sin autorización, comuníquese con el editor e indique la fuente para la reimpresión.
Como DBA, creo que debe haber lidiado con el retraso maestro-esclavo Recientemente, me encontré con un interesante problema de retraso en la producción, y me gustaría compartirlo con ustedes aquí.
Primero mire el monitoreo relacionado del retraso de MySQL:
Es posible que haya descubierto que esta curva de monitoreo es diferente de las curvas de retardo comunes, mostrando principalmente las siguientes dos características:
1. Las curvas de subida y bajada retrasadas son casi rectas hacia arriba y hacia abajo, no un crecimiento lento, sino un cambio repentino.
2. El punto más alto de la curva de retardo es constante.
A través de la configuración de monitoreo, sabemos que la detección de retraso obtiene el valor de Seconds_Behind_Master. Ahora que hay cambios regulares, podemos usar un comando simple para tomar el valor de Seconds_Behind_Master para ver si es consistente con los cambios de la curva monitoreada.
# 观察曲线，五分钟内延迟会出现多次变化，所以本次共抓取5分钟，300次的Seconds_Behind_Master值
for i in {1..300}
do
echo `date` `mysql -S /data/mysql/3306/data/mysqld.sock -uxxx -pxxx -e 'show slave status\G' | grep Second` >>/tmp/second.log
sleep 1
done
Verifique el contenido de /tmp/second.log, puede ver que el valor de Seconds_Behind_Master salta repetidamente entre 0 y 71.
¿Por qué ocurriría tal fenómeno? Según la experiencia pasada, la alta probabilidad de este retraso no se debe a la presión sobre la base de datos, porque el cambio de la curva de retraso es demasiado regular. Desde otras perspectivas, en el proceso de comparación de la hora de los servidores maestro y esclavo, finalmente se capturó una información clave: la diferencia horaria entre la hora de la biblioteca esclava y la biblioteca maestra es básicamente 71S, que coincide con el valor máximo de Seconds_Behind_Master salto de 71.
Algunas personas pueden preguntar, ¿Secons_Behind_Master no restará automáticamente la diferencia horaria al calcular? Sí, podemos ver en la documentación oficial que después de que se inicie el subproceso de IO, Seconds_Behind_Master restará automáticamente la diferencia de tiempo al calcular, pero una premisa muy importante es que esta diferencia de tiempo "no cambiará" después de que se inicie el subproceso de IO.
Por lo tanto, una posibilidad de un gran salto de retraso es que después de que se inicia el subproceso IO, la biblioteca esclava realiza la corrección de tiempo a través de NTP u otros métodos, lo que genera un error en el cálculo de Seconds_Behind_Master.
Entonces, ¿cómo resolverlo? Una solución simple es reiniciar el subproceso IO de la biblioteca esclava y dejar que vuelva a calcular la diferencia entre los tiempos del servidor. Sin embargo, este enfoque puede hacer que reaparezcan los saltos de retardo. La solución óptima es corregir primero la hora de todos los servidores del clúster y luego reiniciar el subproceso de E/S cuando la hora sea coherente. Antes de corregir la hora del servidor, hay algunos puntos que requieren nuestra atención:
Primero, ¿la empresa utiliza una función que llama la hora del sistema? Un escenario posible es: iniciar sesión directamente en el servidor de la base de datos para importar secuencias de comandos SQL En este momento, ajustar la hora del servidor es arriesgado y debe ser evaluado por el lado comercial.
En segundo lugar, al corregir la hora, ¿la hora de la biblioteca principal se corrige hacia adelante o hacia atrás? Normalmente, el impacto comercial de la corrección de tiempo hacia adelante (por ejemplo, 00:03 se corrige a 23:58) es mayor que el de la corrección hacia atrás. Por ejemplo, al insertar un dato, el campo de tiempo create_time es 00: 03, y luego el tiempo se corrige a 23: 58. Después de la corrección, se realiza una operación de actualización antes de 00: 03. En este momento, el fenómeno ese update_time es antes de que aparezca create_time.
En tercer lugar, al realizar la corrección de tiempo, si la diferencia de tiempo es demasiado grande, puede realizar correcciones lentas varias veces, es decir, controlar el rango de tiempo de cada corrección, en lugar de corregir a la hora correcta a través de una operación, para que pueda Minimizar el impacto en el negocio.
Una sugerencia es: si la lógica comercial depende en gran medida del campo de tiempo, una forma confiable es detener la conexión de la aplicación o configurarla como de solo lectura, y luego realizar la corrección de tiempo y reiniciar el subproceso IO.
Referencia: https://dev.mysql.com/doc/refman/5.7/en/show-slave-status.html