mysql_1 | 2025-01-16T08:43:10.095490Z 25 [ERROR] InnoDB: Database page corruption on disk or a failed file read of page [page id: space=174, page number=5238]. You may have to recover from a backup.
mysql_1 | 2025-01-16T08:43:10.095509Z 25 [Note] InnoDB: Page dump in ascii and hex (16384 bytes):
len 16384; hex 3e081ffd000014760000147500001477000000027fd76b6045bf0000000000000000000000ae00273b63809d000000003af80002009a009b0000000000000000000000000000000001a7000000000000000000000000000000000000000 ....略
mysql_1 | InnoDB: End of page dump
mysql_1 | 2025-01-16T08:43:10.146840Z 25 [Note] InnoDB: Uncompressed page, stored checksum in field1 1040719869, calculated checksums for field1: crc32 3660520353/2643644136, innodb 1337455922, none 3735928559, stored checksum in field2 1040719869, calculated checksums for field2: crc32 3660520353/2643644136, innodb 2232905543, none 3735928559, page LSN 2 2144824160, low 4 bytes of LSN at page end 2144824160, page number (if stored to page already) 5238, space id (if created with >= MySQL-4.1.1 and stored already) 174
mysql_1 | InnoDB: Page may be an index page where index id is 423
mysql_1 | 2025-01-16T08:43:10.146878Z 25 [Note] InnoDB: Index 423 is `PRIMARY` in table `库名`.`表名`
mysql_1 | 2025-01-16T08:43:10.146889Z 25 [Note] InnoDB: It is also possible that your operating system has corrupted its own file cache and rebooting your computer removes the error. If the corrupt page is an index page. You can also try to fix the corruption by dumping, dropping, and reimporting the corrupt table. You can use CHECK TABLE to scan your table for corruption. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery.
mysql_1 | 2025-01-16T08:43:10.146901Z 25 [ERROR] [FATAL] InnoDB: Aborting because of a corrupt database page in the system tablespace. Or, there was a failure in tagging the tablespace as corrupt.
mysql_1 | 2025-01-16 16:43:10 0x7fc65c418700 InnoDB: Assertion failure in thread 140489928050432 in file ut0ut.cc line 942
mysql_1 | InnoDB: We intentionally generate a memory trap.
mysql_1 | InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
mysql_1 | InnoDB: If you get repeated assertion failures or crashes, even
mysql_1 | InnoDB: immediately after the mysqld startup, there may be
mysql_1 | InnoDB: corruption in the InnoDB tablespace. Please refer to
mysql_1 | InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
mysql_1 | InnoDB: about forcing recovery.
mysql_1 | 08:43:10 UTC - mysqld got signal 6 ;
mysql_1 | This could be because you hit a bug. It is also possible that this binary
mysql_1 | or one of the libraries it was linked against is corrupt, improperly built,
mysql_1 | or misconfigured. This error can also be caused by malfunctioning hardware.
mysql_1 | Attempting to collect some information that could help diagnose the problem.
mysql_1 | As this is a crash and something is definitely wrong, the information
mysql_1 | collection process might fail.
mysql_1 |
mysql_1 | key_buffer_size=8388608
mysql_1 | read_buffer_size=131072
mysql_1 | max_used_connections=15
mysql_1 | max_threads=151
mysql_1 | thread_count=14
mysql_1 | connection_count=14
mysql_1 | It is possible that mysqld could use up to
mysql_1 | key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68196 K bytes of memory
mysql_1 | Hope that's ok; if not, decrease some variables in the equation.
mysql_1 |
mysql_1 | Thread pointer: 0x7fc600000ae0
mysql_1 | Attempting backtrace. You can use the following information to find out
mysql_1 | where mysqld died. If you see no messages after this, something went
mysql_1 | terribly wrong...
mysql_1 | stack_bottom = 7fc65c417e80 thread_stack 0x40000
mysql_1 | mysqld(my_print_stacktrace+0x2c)[0x55926b267fbc]
mysql_1 | mysqld(handle_fatal_signal+0x479)[0x55926ab92c29]
mysql_1 | /lib/x86_64-linux-gnu/libpthread.so.0(+0x110e0)[0x7fc6822a90e0]
mysql_1 | /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x7fc680a35fff]
mysql_1 | /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fc680a3742a]
mysql_1 | mysqld(+0x6292a3)[0x55926ab692a3]
mysql_1 | mysqld(_ZN2ib5fatalD1Ev+0x12d)[0x55926b43862d]
mysql_1 | mysqld(_Z20buf_page_io_completeP10buf_page_tb+0x362)[0x55926b4746e2]
mysql_1 | mysqld(_Z13buf_read_pageRK9page_id_tRK11page_size_t+0x44a)[0x55926b4a3f7a]
mysql_1 | mysqld(_Z16buf_page_get_genRK9page_id_tRK11page_size_tmP11buf_block_tmPKcmP5mtr_tb+0x4aa)[0x55926b472e4a]
mysql_1 | mysqld(_Z27btr_cur_search_to_nth_levelP12dict_index_tmPK8dtuple_t15page_cur_mode_tmP9btr_cur_tmPKcmP5mtr_t+0x7b6)[0x55926b454a66]
mysql_1 | mysqld(+0xe68c79)[0x55926b3a8c79]
mysql_1 | mysqld(_Z15row_search_mvccPh15page_cur_mode_tP14row_prebuilt_tmm+0x1b9e)[0x55926b3afa1e]
mysql_1 | mysqld(_ZN11ha_innobase10index_readEPhPKhj16ha_rkey_function+0x244)[0x55926b2ab614]
mysql_1 | mysqld(_ZN7handler17ha_index_read_mapEPhPKhm16ha_rkey_function+0x2cf)[0x55926abe483f]
mysql_1 | mysqld(+0xac70e4)[0x55926b0070e4]
mysql_1 | mysqld(_Z10sub_selectP4JOINP7QEP_TABb+0x105)[0x55926b00a3a5]
mysql_1 | mysqld(+0xac4dda)[0x55926b004dda]
mysql_1 | mysqld(_Z10sub_selectP4JOINP7QEP_TABb+0x170)[0x55926b00a410]
mysql_1 | mysqld(_ZN4JOIN4execEv+0x370)[0x55926b003210]
mysql_1 | mysqld(_Z12handle_queryP3THDP3LEXP12Query_resultyy+0x233)[0x55926b0726c3]
mysql_1 | mysqld(+0x61d1d2)[0x55926ab5d1d2]
mysql_1 | mysqld(_Z21mysql_execute_commandP3THDb+0x460d)[0x55926b035f1d]
mysql_1 | mysqld(_Z11mysql_parseP3THDP12Parser_state+0x395)[0x55926b0387e5]
mysql_1 | mysqld(_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0xfc4)[0x55926b0398a4]
mysql_1 | mysqld(_Z10do_commandP3THD+0x197)[0x55926b03ac77]
mysql_1 | mysqld(handle_connection+0x278)[0x55926b0f7778]
mysql_1 | mysqld(pfs_spawn_thread+0x1b4)[0x55926b5cfc34]
mysql_1 | /lib/x86_64-linux-gnu/libpthread.so.0(+0x74a4)[0x7fc68229f4a4]
mysql_1 | /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7fc680aebd0f]
mysql_1 |
mysql_1 | Trying to get some variables.
mysql_1 | Some pointers may be invalid and cause the dump to abort.
mysql_1 | Query (7fc600005640): SELECT count(*) AS count_1 FROM (SELECT ...略 sql语句
mysql_1 | Connection ID (thread ID): 25
mysql_1 | Status: NOT_KILLED
mysql_1 |
mysql_1 | The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
mysql_1 | information that should help you find out what is causing the crash.
mysql_1 | 2025-01-16T08:43:14.280405Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
mysql_1 | 2025-01-16T08:43:14.281938Z 0 [Note] mysqld (mysqld 5.7.26-log) starting as process 1 ...
mysql_1 | 2025-01-16T08:43:14.285411Z 0 [Note] InnoDB: PUNCH HOLE support available
mysql_1 | 2025-01-16T08:43:14.285434Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
mysql_1 | 2025-01-16T08:43:14.285439Z 0 [Note] InnoDB: Uses event mutexes
mysql_1 | 2025-01-16T08:43:14.285444Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
mysql_1 | 2025-01-16T08:43:14.285448Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11-
配置文件增加, 并重启mysql
innodb_force_recovery=1
-
使用mysqldump 把如上错误的表数据先备份
mysqldump使用 -
把原表删除或者改名, 这步需要谨慎操作
-
再使用把先前备份的数据导入,
-
再去查询数据,就不会出现上面的问题了,但是丢失的数据是没有办法找回的
-
最后innodb_force_recovery恢复,并重新mysql
像我这种情况其中一个表在操作的时候,就出现中间一小部分备份不出来,一备份就宕机, 只能跳过处理, 最后缺失的数据从以前的备份文件里找到出来进行恢复的
mysqldump -u root -p 库名 表名 --where="id < 267270" > table_part_1.sql
mysqldump -u root -p 库名 表名 --where="id > 267356" --no-create-info > table_part_2.sql