Fuente: Cuenta pública "The Shadow Corridor of the Oracle"
En una estructura de replicación asincrónica o semisincrónica, los retrasos de la biblioteca son bastante normales.
Aunque el retraso es normal, la empresa generalmente evalúa si necesita atención.
Por ejemplo, hay servicios de lectura que requieren una mayor coherencia de la biblioteca, y se requiere que el retraso sea menor que cierto valor, entonces debe prestar atención.
Una breve descripción general de la lógica de replicación:
1. La base de datos principal registra los cambios en la instancia de la base de datos en binlog.
2. La biblioteca principal tendrá un binlog dumphilo para monitorear los cambios del binlog en tiempo real y enviar estos nuevos eventos a la biblioteca esclava ( Master has sent all binlog to slave; waiting for more updates)
3. La biblioteca esclava IO Threadrecibe estos eventos y los registra en el registro de relés.
4. SQL ThreadLea los eventos de registro de retransmisiones de la biblioteca y aplique (o vuelva a reproducir) estos eventos a la instancia de la biblioteca esclava.
La anterior es la lógica de replicación asincrónica predeterminada, y la replicación semisincrónica es ligeramente diferente, por lo que no la repetiré aquí.
Además, juzgar que hay un retraso en la biblioteca esclava es un asunto muy simple:
simplemente pase el valor de SHOW SLAVE STATUS
verificación en la biblioteca esclava Seconds_Behind_Master.
Razones del retraso y soluciones
〇Las solicitudes DML de la biblioteca principal son frecuentes (tps grandes)
Es decir, la biblioteca principal tiene muchas solicitudes de escritura, una gran cantidad de operaciones simultáneas de inserción, eliminación y actualización, y se genera una gran cantidad de binlog en poco tiempo.
[Análisis de causas] La
biblioteca principal escribe datos al mismo tiempo, mientras que la biblioteca esclava SQL Threades un registro de aplicación de un solo subproceso, lo que puede causar fácilmente la acumulación y el retraso del registro de retransmisión.
[Solución]
Realice la fragmentación y divida las solicitudes de escritura mediante la escalabilidad horizontal. O considere actualizar a MySQL 5.7+ y habilite la replicación paralela basada en relojes lógicos.
〇La biblioteca principal realiza tareas importantes
Por ejemplo, una gran cantidad de datos de importación INSERT INTO $tb1 SELECT * FROM $tb2, LOAD DATA INFILEcomo
por ejemplo UPDATE, DELETEtoda la tabla y por lo tanto se Exec_Master_Log_Posha mantenido igual, Slave_SQL_Running_Statepara el Reading event from the relay log
análisis del binlog de la biblioteca principal, se puede conocer la biblioteca principal que actualmente ejecuta la transacción.
[Análisis de la causa]
Si la base de datos maestra tarda 200 segundos en actualizar una tabla grande, si la configuración de las bibliotecas maestra y esclava es similar, la biblioteca esclava también necesita dedicar casi el mismo tiempo a actualizar la tabla grande. En este momento, el retraso de la biblioteca esclava comienza a acumularse y los eventos posteriores No se pudo actualizar.
[Solución]
Divida las transacciones grandes y envíelas a tiempo.
〇La biblioteca principal ejecuta declaraciones DDL en tablas grandes
Fenómeno y 主库执行大事务similar.
Compruebe que Exec_Master_Log_Pos no se haya movido o que esté ejecutando DDL.
Analice el binlog de la biblioteca principal y vea las transacciones actualmente ejecutadas por la biblioteca principal.
[Razones]
1, DDL no se inicia, bloqueado, SHOW SLAVE STATUSrevisados Slave_SQL_Running_Stateen waiting for table metadata lock, y Exec_Master_Log_Posque no cambia.
2. Se está ejecutando DDL y SQL Threadlas aplicaciones de un solo subproceso provocan un aumento de las demoras. Slave_SQL_Running_StatePorque altering table, Exec_Master_Log_Possin cambios
[Soluciones]
por processlisto information_schema.innodb_trxpara encontrar las sentencias DDL de consulta de bloqueo, deshacerse de las consultas, para que DDL se ejecute correctamente desde la biblioteca.
La demora causada por DDL en sí es difícil de evitar. Se recomienda considerar:
① Después de que se ejecuta el período pico comercial
② set sql_log_bin=0, ejecute manualmente DDL en las bibliotecas maestra y esclava (esta operación causará inconsistencia de datos para algunas operaciones DDL, asegúrese de probar estrictamente)
〇 La configuración de la biblioteca maestra y la biblioteca esclava son inconsistentes:
[Análisis de la causa]
Hardware: el servidor de instancia de la biblioteca principal usa SSD, mientras que el servidor de instancia de la biblioteca esclavo usa discos SAS normales y la frecuencia de la CPU es inconsistente.
Configuraciones: como estrategias de escritura de tarjetas RAID inconsistentes, configuraciones inconsistentes de los parámetros del kernel del sistema operativo y estrategias de ubicación de disco MySQL inconsistentes Espere
[Idea de solución]
Intente unificar la configuración de la máquina de base de datos (incluidos los parámetros de hardware y opciones).
Incluso para algunos servicios OLAP, la configuración de hardware de la instancia de la biblioteca esclava es mayor que la de la biblioteca principal, etc.
〇La tabla carece de clave principal o índice único
binlog_format=rowDadas las circunstancias, si la tabla carece de una clave principal o de un índice único UPDATE, el DELETEtiempo puede provocar un retraso debido al aumento de la biblioteca.
Esta vez Slave_SQL_Running_Statees Reading event from the relay log.
Y SHOW OPEN TABLES WHERE in_use=1la mesa siempre existe. Exec_Master_Log_Posconstante.
La cpu del proceso mysqld es casi del 100% (cuando no hay servicio de lectura), la presión de io no es grande
] [El análisis de la causa
se supone que en casos extremos, la base de datos maestra actualiza 500w 20w filas en la tabla, la declaración de actualización requiere una tabla completa escanea
el siguiente formato de fila, se registra binlog 20w tiempos de operación de actualización, luego el SQL Threadpeso La colocación será muy lenta, cada actualización puede requerir un escaneo completo de la tabla
[Idea de solución]
Verifique la estructura de la tabla para asegurarse de que cada tabla tenga una clave primaria explícita que aumente automáticamente y establezca los índices adecuados.
〇La presión de la propia biblioteca es demasiado alta
[Análisis de causa]
Se ejecuta una gran cantidad de solicitudes seleccionadas desde la biblioteca, o la mayoría de las solicitudes seleccionadas de la empresa se enrutan a la instancia de la biblioteca esclava, incluso una gran cantidad de servicios OLAP, o se está realizando una copia de seguridad de la biblioteca esclava.
En este momento, la carga de la CPU puede ser demasiado alta y la tasa de utilización de io puede ser demasiado alta, lo que resulta en una aplicación de subprocesos SQL demasiado lenta.
[Solución]
Cree más bibliotecas esclavas, divida las solicitudes de lectura y reduzca la presión sobre las instancias de bibliotecas esclavas existentes.
〇Motor de almacenamiento MyISAM
En este momento de la biblioteca Slave_SQL_Running_StateesWaiting for table level lock
[Análisis de causas]
MyISAM solo admite bloqueos a nivel de tabla y las operaciones de lectura y escritura no se pueden realizar al mismo tiempo.
En @@concurrent_insertel caso de establecer el valor correspondiente, la biblioteca principal puede ejecutar insert simultáneamente durante la selección, pero SQL Threadno se puede reproducir simultáneamente desde la biblioteca.Si está interesado, puede ir a ver la implementación de myisam.
[Solución]
Por supuesto, elegí perdonarlo, ya que elegí MyISAM, también debería estar psicológicamente preparado. (Hay otros escenarios, y no se recomienda usar MyISAM en la estructura de replicación)
Cambiar a InnoDB.
para resumir:
Pasar SHOW SLAVE STATUSy SHOW PROCESSLISTver la situación actual desde la biblioteca. (Por cierto, esta razón también se puede descartar al hacer una copia de seguridad de la biblioteca).
Si sigue Exec_Master_Log_Possiendo el mismo, considere transacciones grandes, DDL y ninguna clave principal, y verifique el binlog y la posición correspondiente a la biblioteca principal.
Si Exec_Master_Log_Poscambia, el retraso aumentará gradualmente, considere la carga de la máquina de la biblioteca esclava, como io, cpu, etc., y considere si la operación de escritura de la biblioteca principal y la presión de la biblioteca esclava en sí son demasiado grandes.
Si no se presenta ninguna de las razones anteriores, pregunte a los líderes de DBA.
Por supuesto, no Seconds_Behind_Masteres necesariamente exacto En una pequeña cantidad de escenarios, aunque Seconds_Behind_Masteres 0, los datos del maestro y del esclavo son inconsistentes.
Esta será otra publicación de blog.
El texto completo ha terminado.
Disfruta MySQL :)
Escanee el código QR para seguir la cuenta pública de WeChat del autor
La clase "MySQL Core Optimization" de Teacher Ye se ha actualizado a MySQL 8.0, escanee el código para comenzar el viaje de la práctica de MySQL 8.0