En las arquitecturas de alta disponibilidad MySQL, la replicación primaria de bases de datos es un tipo muy común.
Cuando la base de datos primaria se cae, puedes actualizar una base de datos esclava como una nueva base de datos primaria para asegurar la disponibilidad del servicio. Al mismo tiempo, el QPS de todo el clúster puede mejorarse ampliando la biblioteca esclava.
Bajo la arquitectura de replicación maestro-esclavo, MySQL utiliza binlog para lograr la consistencia de datos maestro-esclavo.
Como se muestra en la figura anterior, la replicación de maestro-esclavo de MySQL tiene principalmente los siguientes pasos
1. Registrar los cambios en el registro binario
2. El esclavo io_thread solicitar el binlog de la biblioteca principal y escribir el binlog resultante en el log de relé
3. Eventos de sql_thread de rehacer esclavos en el registro de relevos
Además de ser un enlace para la replicación maestro-esclavo de MySQL, binlog también cumple otros propósitos. Como qué:
1. Utilizar la herramienta mysqlbinlog para analizar el archivo binlog y realizar la recuperación de bases de datos en un momento en el tiempo.
2. Flashback de la base de datos basado en eventos binlog (MariaDB puede usar directamente mysqlbinlog para flashback)
3. La herramienta de cambio de tablas en línea de código abierto de Github, gh-ost, también está implementada mediante binlog
4. También puedes suscribirte y consumir incrementalmente analizando binlogs
Binlog es muy útil, pero es inevitable que encuentres algunos problemas en el proceso diario de operación y mantenimiento. Aquí tienes algunos errores relacionados con binlogs.
Una de las preguntas frecuentes
Fenómeno
Mysqlbinlog5.5 analiza el archivo binlog Mysql5.7 Aparece
ERROR: Error in Log_event::read_log_event(): 'Sanity check failed', data_len: 31, event_type: 35ERROR: Could not read entry at offset 123: Error in log format or read error.
Análisis de la causa
MySQL 5.6 y otras versiones superiores de archivos binlog han añadido nuevos eventos binlog, como eventos GTID.
mysqlbinlog en mysql5.5 no reconoce tales eventos binlog.
Solución alternativa
Utiliza la versión superior de mysqlbinlog para resolver el binlog generado por la versión inferior de mysql
Pregunta frecuente dos
Fenómeno
Aparece un servidor mysql en buen estado de esclavo
Last_SQL_Error: Fallo en la lectura del registro del relé: No se pudo analizar la entrada del evento del registro del relé.
Las posibles razones son: el registro binario del maestro está corrompido (puedes comprobarlo ejecutando 'mysqlbinlog' en el registro binario),
El registro de relé del esclavo está corrompido (puedes comprobarlo ejecutando 'mysqlbinlog' en el registro de relé),
un problema de red, o un error en el código MySQL del maestro o esclavo.
Si quieres comprobar el registro binario del maestro o el registro de relé del esclavo,
podrás saber sus nombres emitiendo 'MOSTRAR ESTATUS DE ESCLAVO' sobre este esclavo.
Análisis de la causa
Las entradas en el registro de relé no pueden leerse debido a errores binlog en la biblioteca maestra, errores de registro de retransmisión en la biblioteca esclava o problemas y fallos de red. Normalmente es causado por una falla en la red o una presión excesiva sobre la biblioteca esclava, lo que resulta en un formato incorrecto del registro de relé.
Solución alternativa
Tras encontrar el momento de sincronización actual y restablecer la sincronización maestro-esclavo, se generará un nuevo registro de relé y se restaurará la sincronización maestro-esclavo.
A partir de la salida de "mostrar estado esclavo\G", encuentra la siguiente información:
Relay_Master_Log_File: mysql-bin.002540 // El binlogExec_Master_Log_Pos del maestro leído por la biblioteca esclava: 950583017 // El punto de posición que se ha ejecutado sobre el esclavo
Detener el esclavo y volver a configurar la sincronización empezando desde el archivo binlog que el esclavo ha leído y la posición que se ha ejecutado.
Relay_Master_Log_File: mysql-bin.002540 // El binlogExec_Master_Log_Pos del maestro leído por la biblioteca esclava: 950583017 // El punto de posición que se ha ejecutado sobre el esclavo
Pregunta frecuente tres
Fenómeno
Restaurar el estado de esclavo de mostrar error tras el tiempo de inactividad:
Last_SQL_Error: Error inicializando la posición del registro del relé: error de E/S al leer la cabecera del registro binario
Last_SQL_Error: Error inicializando la posición del registro del relé: Binlog tiene un número mágico incorrecto; No es un archivo de registro binario que pueda usar esta versión de MySQL
Análisis de la causa
Inactividades, como cortes de energía, quemas de placa base, etc., o apagados ilegales, que pueden causar corrupción del archivo del relé.
Solución alternativa
Misma pregunta dos.
relay_log_recovery = 1 también puede establecerse.
Cuando el esclavo se cae de la biblioteca, si el registro de relé se corrompe y parte del registro de relé no se procesa, el registro de relé se abandona automáticamente y el registro se recupera del maestro, completando la recuperación del registro de relé.
Pregunta frecuente cuatro
Fenómeno
Aparece cuando cambia el master a después de que se caiga un reinicio desde la máquina de la biblioteca
Error (Código 1201): No se pudo inicializar la estructura maestra de información; se pueden encontrar más mensajes de error en el registro de errores de MySQL
o
ERROR 1872 (HY000): El esclavo no pudo inicializar la estructura de información del registro de relé desde el repositorio
Análisis de la causa
Inactividades, como cortes de corriente, quemaduras en la placa base, etc., o apagado ilegal, que pueden dañar archivos master.info o realy-log.info
Solución alternativa
esclavo> reiniciar esclavo todo, cambiar maestro a
Medidas preventivas
Configuración del perfil
relay_log_info_repository=tabla
master_info_repository=tabla
El motor de almacenamiento de MySQL 5.6.5 mysql.slave_master_info y mysql.slave_relay_log_info está configurado como MyISAM por defecto, y necesitas cambiarlo al motor de almacenamiento de InnoDB
ALTER TABLE mysql.slave_master_info ENGINE=InnoDB;
ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;
mysql.slave_master_info tabla se actualizará tras sync_master_info eventos.
mysql.slave_relay_log_info tabla se actualizará con cada commit de transacción.
Pregunta frecuente 5
Fenómeno
El esclavo maestro binlog_format originalmente una sentencia, tras cambiar la base de datos principal binlog_format a row, mostrar estado esclavo aparece desde la biblioteca:
Last_Error: Error al ejecutar evento de fila: 'No se puede ejecutar la sentencia: imposible escribir en un registro binario ya que la sentencia está en formato de fila y BINLOG_FORMAT = SENTENCIA.'
Análisis de la causa
Cuando la binlog_format principal de la base de datos es row, y la binlog_format de la biblioteca esclava es la instrucción, aparecerá el error anterior.
Pero la biblioteca principal binlog_format es la declaración, y la biblioteca de esclavos binlog_format fila;
O si la binlog_format principal de la base de datos es una fila, el error no se reportará si la binlog_format de la base de datos está mezclada.
Si tu hilo SQL está realmente configurado con
binlog_format=SENTENCIA: una vez recibe un evento ROW, se detendrá. El
la razón es que no podría registrar ese evento ROW en formato STATEMENT (a veces lo llamamos inyección ROW, que es o bien un
Instrucción BINLOG o un evento ROW ejecutado por el hilo SQL del esclavo)
Referencia detallada de la razón:https://bugs.mysql.com/bug.php?id=69095
Solución alternativa
ESCLAVO> CLAVO DE PARADA;
ESCLAVO> CONJUNTO GLOBAL binlog_format=MIXTO;
ESCLAVO> ESCLAVO INICIAL;
Pregunta frecuente número 6
Fenómeno
Error al sincronizar mysql5.6 con mysql5.5
Last_IO_Error: Detecté el error fatal 1236 del maestro al leer datos del registro binario: 'El esclavo no puede gestionar eventos de replicación con la suma de comprobación que el maestro está configurado para registrar; El primer evento 'mysql-bin.000001' a las 4, el último evento leído desde 'mysql-bin.000001' a 120, el último byte leído desde 'mysql-bin.000001' a 120.'
Análisis de la causa
Para solucionar el problema de que las sentencias SQL que se ejecutan en el servidor principal son inconsistentes con las sentencias SQL que se ejecutan en el servidor (llamado evento corrupto) debido a errores de software y hardware o transmisión en red, MySQL 5.6 añade la función de suma de verificación de eventos de replicación. Cuando un evento se escribe en el registro binario, también se escribe la suma de comprobación en el registro binario, y luego, tras transmitirse al esclavo a través de la red, se verifica en el esclavo y se escribe en el registro de relé del esclavo. Como los eventos y las sumas de comprobación se registran en cada paso, podemos averiguar rápidamente cuál es el problema.
En mysql5.6.5 y versiones posteriores binlog_checksum el valor predeterminado es crc32,
El valor predeterminado binlog_checksum versión anterior era ninguno
solución
Esclavo> conjunto global binlog_checksum=ninguno
Pregunta frecuente 7
Fenómeno
Cuando el disco esté lleno, limpia manualmente el archivo binlog y el archivo mysql-bin.index
Los registros binarios de mostrar están vacíos, pero el estado de mostrar maestro es normal.
mysql> mostrar registros binarios; Conjunto vacío (0,00 seg)mysql> mostrar estado maestro;
+------------------+-----------+--------------+------------------+
| Archivo | Posición | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
Análisis de la causa
Después de revisar el archivo mysql-bin.index, encontré la primera línea en blanco.
En el código fuente de mysql rpl_master.cc:show_binlogs() encontrarás el siguiente código:
/* The file ends with EOF or empty line */
mientras que ((longitud=my_b_gets(index_file, nombre, tamañode(nombre))) > 1)
Las líneas en blanco se consideran el final del documento
(Referencia.)https://yq.aliyun.com/articles/213657Artículo)
Medidas preventivas
No borres binlog manualmente, no edites manualmente el archivo mysql-bin.index, a menos que sepas lo que haces, si no, podrías estar colocando minas para ti mismo.
resumen
Los DBA deben prestar atención a las mejoras en binlog en cada nueva versión de MySQL (como la función gtid añadida en la versión 5.6, los esclavos multihilo mejorados en la versión 5.7), y entender el significado de cada parámetro en detalle, para poder saber qué significa cuando se encuentran con errores y resuelven problemas fácilmente.
|
Publicado en 25/9/2018 10:31:40
|
|
|
|
