Análisis de fallas | Análisis de casos de errores de sincronización maestro-esclavo de MySQL después de reiniciar después de una falla del esclavo
El mensaje de error muestra que al reproducir la transacción "471c2974-f9bb-11eb-afb1-52540010fb89:88313207", Debido al conflicto de clave principal del registro que se va a insertar, el hilo de trabajo informó un error.
Antes de que se reinicie el host, la sincronización maestro-esclavo es normal. Después de que se reinicia el host, la sincronización maestro-esclavo falla debido a un conflicto de clave maestra. El mismo conflicto se registra en el repositorio maestro-esclavo. /p>
En comparación con la clave maestra, el análisis preliminar de la transacción '471c2974-f9bb-11eb-afb1-52540010fb89:88313207' en la falla del host
La biblioteca esclava completó la reproducción antes de la falla. ¿Por qué es necesario volver a reproducir la transacción?
Cuando el modo gtid está activado, si se especifica master_auto_position=1, al iniciar el dispositivo esclavo, el dispositivo esclavo enviará el conjunto combinado de Retrieved_Gtid_Set y Executed_Gtid_Set al dispositivo maestro. Luego, el maestro fusiona el conjunto recibido merge set con su propio
gtid_executed y envía cualquier transacción que falte en el conjunto gtid del esclavo al esclavo.
Después de que se reinicia el host, la transacción se reproduce repetidamente, lo que indica que la transacción GTID falta en el conjunto de concatenación de Retrieved_Gtid_Set y Executed_Gtid_Set
, lo que resulta en una recuperación repetida de la transacción en ejecutarse, provocando un error de conflicto de clave principal. Retrieved_Gtid_Set y Executed_Gtid_Set son variables de memoria
Después de reiniciar MySQL, Retrieved_Gtid_Set se inicializará para vaciarlo, infiriendo así que una transacción GTID se pierde en Executed_Gtid_Set.
Executed_Gtid_Set se deriva de la variable gtid_executed, que persiste en la
tabla mysql.gtid_executed y binlog, donde la tabla mysql.gtid_executed se introdujo después de MySQL 5.7. La tabla mysql.gtid_executed se introdujo después de MySQL 5.7. En MySQL 5.6, para usar GTID en un esclavo, debe configurar log_bin=on,log_slave_updates=on porque el GTID ejecutado por el esclavo solo se guarda en el binlog.
La variable gtid_executed está obsoleta y se infiere que el binlog no se ha conservado en tiempo real. Echemos un vistazo a los parámetros de sync_binlog:
A través del análisis anterior, el La causa y el efecto de esta falla son claros de un vistazo:
p>
El hilo de trabajo informó un error de conflicto de clave principal 1062 --> la información de gtid_executed está obsoleta --> la información de gtid_executed está obsoleta --> gtid_executed la información está obsoleta --> la información ejecutada está obsoleta --> binlog no tiene persistencia en tiempo real
Cree un entorno de prueba que contenga una estación maestra y una estación esclava, simule la inserción simultánea de la estación maestra a través sysbench y reproduzca la falla después de que el host de la estación esclava se apague violentamente:
Dado que la causa del error es la ejecución repetida de la transacción, simplemente omita este error. Hay dos métodos, elija uno. según sus necesidades. Método de ejecución:
Si el último binglog pierde más GTID, la ejecución manual será más problemática y requerirá prueba y error constantes. Puede escribir un programa para ejecutarlos en lotes:
Después de que la sincronización maestro-esclavo sea normal, cancele la configuración de Slave_skip_errors y reinicie MySQL.