Abstract: Hoy les traigo un caso de reparación de caída de base de datos MySQL
Este artículo es compartido por la comunidad HUAWEI CLOUD " Recuerde un caso de reparación de fallas de MySQL, no es necesario eliminar la base de datos y salir corriendo ", autor: Glacier.
Descripción del problema
Mientras estudiaba el código fuente de MySQL, depuraba y sometía a prueba el código fuente de MySQL, ¡MySQL colapsó! ¡El problema es que en realidad falla! ¡Y también archivos corruptos de InnoDB! ! Afortunadamente, sucedió en el entorno de depuración. Veamos rápidamente cómo resolver este problema. Después de una serie de procesos como acceso a datos, verificación, comparación, depuración y seguimiento del código fuente de MySQL, reparación de archivos InnoDB dañados y resumen, este artículo es organizado en este artículo. En el futuro, si el entorno de producción en línea realmente sucede, no tiene que preocuparse por salir corriendo. ¡Puede resolver el problema de bloqueo de MySQL en minutos! ! Verifique el registro de errores de la siguiente manera:
-----------------------------------------
161108 23:36:45 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/var
2022-08-25 23:36:46 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2022-08-25 23:36:46 5497 [Note] Plugin 'FEDERATED' is disabled.
2022-08-25 23:36:46 7f11c48e1720 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
2022-08-25 23:36:46 5497 [Note] InnoDB: Using atomics to ref count buffer pool pages
2022-08-25 23:36:46 5497 [Note] InnoDB: The InnoDB memory heap is disabled
2022-08-25 23:36:46 5497 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2022-08-25 23:36:46 5497 [Note] InnoDB: Memory barrier is not used
2022-08-25 23:36:46 5497 [Note] InnoDB: Compressed tables use zlib 1.2.3
2022-08-25 23:36:46 5497 [Note] InnoDB: Using CPU crc32 instructions
2022-08-25 23:36:46 5497 [Note] InnoDB: Initializing buffer pool, size = 16.0M
2022-08-25 23:36:46 5497 [Note] InnoDB: Completed initialization of buffer pool
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 5.
InnoDB: You may have to recover from a backup.
2022-08-25 23:36:46 7f11c48e1720 InnoDB: Page dump in ascii and hex (16384 bytes):
len 16384; hex 7478d078000000050000000000000000000000000f271f4d000700000000000000000000000000000000001b4000000000000000000200f20000000000000006000000000000002d000000000000002e000000000000002f0000000000000030000000000（省略很多类似代码）
InnoDB: End of page dump
2022-08-25 23:36:46 7f11c48e1720 InnoDB: uncompressed page, stored checksum in field1 1954074744, calculated checksums for field1: crc32 993334256, innodb 2046145943, none 3735928559, stored checksum in field2 1139795846, calculated checksums for field2: crc32 993334256, innodb 1606613742, none 3735928559, page LSN 0 254222157, low 4 bytes of LSN at page end 254221236, page number (if stored to page already) 5, space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be a transaction system page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 5.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
2022-08-25 23:36:46 7f11c48e1720 InnoDB: Assertion failure in thread 139714288817952 in file buf0buf.cc line 4201
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
03:36:46 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
key_buffer_size=16777216
read_buffer_size=262144
max_used_connections=0
max_threads=1000
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 798063 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
/usr/local/mysql/bin/mysqld(my_print_stacktrace+0x35)[0x8e64b5]
/usr/local/mysql/bin/mysqld(handle_fatal_signal+0x41b)[0x652fbb]
/lib64/libpthread.so.0(+0xf7e0)[0x7f11c44c77e0]
/lib64/libc.so.6(gsignal+0x35)[0x7f11c315d625]
/lib64/libc.so.6(abort+0x175)[0x7f11c315ee05]
/usr/local/mysql/bin/mysqld[0xa585c5]
/usr/local/mysql/bin/mysqld[0xa6c7b4]
/usr/local/mysql/bin/mysqld[0xa6cbc7]
/usr/local/mysql/bin/mysqld[0xa5bce2]
/usr/local/mysql/bin/mysqld[0xa1e2ba]
/usr/local/mysql/bin/mysqld[0xa0bf60]
/usr/local/mysql/bin/mysqld[0x95a427]
/usr/local/mysql/bin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x48)[0x58f788]
/usr/local/mysql/bin/mysqld[0x6e4a36]
/usr/local/mysql/bin/mysqld(_Z11plugin_initPiPPci+0xb3e)[0x6e826e]
/usr/local/mysql/bin/mysqld[0x582d85]
/usr/local/mysql/bin/mysqld(_Z11mysqld_mainiPPc+0x4d8)[0x587d18]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f11c3149d5d]
/usr/local/mysql/bin/mysqld[0x57a019]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
161108 23:36:46 mysqld_safe mysqld from pid file /usr/local/mysql/var/VM_241_49_centos.pid ended
------------------------------------------------------------------------------análisis del problema
Se puede ver en el registro que hay un problema con el motor innodb. El registro solicita http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html para ver el método de recuperación forzada. Busque el campo [mysqld] en el archivo de configuración mysql my.cnf y agregue innodb_force_recovery=1:
[mysqld]
innodb_force_recovery = 1Si innodb_force_recovery=1 no surte efecto, puedes probar varios números del 2 al 6
Luego reinicie mysql, el reinicio es exitoso. Luego use mysqldump o pma para exportar los datos, realizar operaciones de reparación, etc. Una vez completada la reparación, comente el parámetro y restablezca el valor predeterminado de 0.
Parámetros del archivo de configuración: innodb_force_recovery
innodb_force_recovery afecta el estado de recuperación de todo el motor de almacenamiento InnoDB. El valor predeterminado es 0, lo que significa que todas las operaciones de recuperación se realizan cuando se requiere la recuperación (es decir, verificar páginas de datos/purgar deshacer/insertar fusión de búfer/retroceder y avanzar). se registrará un error en el registro;
innodb_force_recovery se puede establecer en 1-6, con números más grandes que contienen los efectos de todos los números anteriores. Cuando el valor del parámetro se establece en un valor superior a 0, puede realizar operaciones de selección, creación y eliminación en la tabla, pero no se permiten operaciones como insertar, actualizar o eliminar.
- (SRV_FORCE_IGNORE_CORRUPT): Ignora las páginas corruptas verificadas.
- (SRV_FORCE_NO_BACKGROUND): evita que se ejecute el subproceso principal. Si el subproceso principal necesita realizar una operación de purga completa, provocará un bloqueo.
- (SRV_FORCE_NO_TRX_UNDO): No realizar operaciones de reversión de transacciones.
- (SRV_FORCE_NO_IBUF_MERGE): no realizar operaciones de fusión en los búferes de inserción.
- (SRV_FORCE_NO_UNDO_LOG_SCAN): sin ver el registro de rehacer, el motor de almacenamiento de InnoDB trata las transacciones no confirmadas como confirmadas.
- (SRV_FORCE_NO_LOG_REDO): No realizar operaciones de avance.
solución
Referencia general del método de reparación:
el primer método
Crear una nueva tabla:
create table demo_bak #和原表结构一样，只是把INNODB改成了MYISAM。datos de importacion
insert into demo_bak select * from demo;Eliminar la tabla original:
drop table demo;Después de comentar innodb_force_recovery, reinicie.
Rebautizar:
rename table demo_bak to demo;Finalmente cambie de nuevo al motor de almacenamiento:
alter table demo engine = innodbel segundo metodo
Otra forma es usar mysqldump para exportar la tabla y luego volver a importarla a la tabla InnoDB. Los resultados de ambos métodos son los mismos.
Exportación de copia de seguridad (incluida la estructura y los datos):
mysqldump -uroot -p123 test > test.sqlMétodo de restauración 1:
use test;
source test.sqlMétodo de restauración 2 (línea de comando del sistema):
mysql -uroot -p123 test < test.sql;Tenga en cuenta que el comando CHECK TABLE es básicamente inútil en las bases de datos InnoDB.
tercer método
1. Configurar mi.cnf
Configure innodb_force_recovery = 1 o 2 - 6 números, reinicie MySQL
2. Script de exportación de datos
mysqldump -uroot -p123 test > test.sqlExportar secuencias de comandos SQL. O importe todas las bases de datos/tablas a bases de datos de otros servidores con Navicat.
Nota: Los datos aquí deben respaldarse correctamente. Luego elimine los datos en la base de datos original.
3. Eliminar ib_logfile0, ib_logfile1, ibdata1
Haga una copia de seguridad de los tres archivos ib_logfile0, ib_logfile1 e ibdata1 en el directorio de datos de MySQL y luego elimine estos tres archivos.
4. Configurar mi.cnf
Elimine la configuración de línea de innodb_force_recovery = 1 o 2 - 6 números en my.cnf o configúrelo como innodb_force_recovery = 0, reinicie el servicio MySQL
5. Importar datos a la base de datos MySQL
mysql -uroot -p123 test < test.sql; 或者用Navicat将备份的数据导入到数据库中。Cuestiones a tener en cuenta en este enfoque:
- Los tres archivos ib_logfile0, ib_logfile1 e ibdata1 deben respaldarse primero y luego eliminarse;
- Asegúrese de confirmar que la exportación de datos original fue exitosa
- Después de que los datos se exporten correctamente, cuando elimine los datos en la base de datos original, si se le indica que no se pueden eliminar, puede ingresar al directorio de datos MySQL en la línea de comando y eliminar manualmente la carpeta de la base de datos relevante o el archivo de la tabla de datos. en la carpeta de la base de datos, siempre que los datos deben ser La exportación o la copia de seguridad se realizó correctamente.
Haga clic en Seguir para conocer las nuevas tecnologías de HUAWEI CLOUD por primera vez~