标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-600 kcratr_nab_less_than_odr ORA-600 kdsgrp1 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (112)
- 数据库 (1,862)
- DB2 (22)
- MySQL (82)
- Oracle (1,688)
- Data Guard (53)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (168)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (72)
- Oracle Bug (8)
- Oracle RAC (56)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (646)
- Oracle安装升级 (106)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (90)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (5)
- 达梦恢复 (3)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (48)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (31)
-
最近发表
- 记录block 0损坏,数据文件大量坏块,使用不当数据库版本恢复等各种操作之后的故障处理
- 需要注意:dbv 检测controlfile可能不准
- 达梦数据库redo异常强制拉库
- dd破坏包含50多个pdb的asm 磁盘组恢复
- Oracle数据库系统回滚段异常处理-ORA-600 4137/4193
- 使用deepseek进行Oracle恢复,引起重大故障
- 接手一个只差临门一脚的数据库恢复
- 硬件故障后数据文件大小不对故障处理—Oracle碎片扫描恢复
- 1.5T MySQL数据库完美恢复
- WARNING: detected duplicate paths to the same disk导致crs无法正常启动故障解决
- asm dd 10M导致system文件部分坏块修复
- Oracle 19c 202604补丁(RUs+OJVM)-19.31
- Oracle故障第一现场被恢复混乱的数据库恢复
- impdp报ORA-39083 ORA-14102错误处理
- 一次断电引起的Oracle故障恢复-ora-600 2662故障
- OraScan(Oracle 碎片扫描工具) 使用说明
- .[xueyuanjie@onionmail.org].AIR勒索加密数据库恢复
- oracleasm createdisk破坏的acfs文件系统恢复
- 先offline数据文件,再resetlogs导致恢复复杂的故障处理
- exp dmp导入报IMP-00098: INTERNAL ERROR: impgst2故障处理
标签归档:MySQL恢复
1.5T MySQL数据库完美恢复
有客户MySQL数据库异常无法正常启动,需要提供恢复支持,当时提供的错误日志信息为:log sequence number xxxx is in the future

2026-06-03T13:35:02.368514Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery.
2026-06-03T13:35:02.369669Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=521127] log sequence number 15319315659882 is in the future! Current system log sequence number 6712970192343.
从头分析mysql的日志,发现最初情况为:
---TRANSACTION 8424429306, ACTIVE 259 sec truncating table mysql tables in use 1, locked 1 0 lock struct(s), heap size 1136, 0 row lock(s) MySQL thread id 4513911, OS thread handle 21996, query id 4194188849 localhost 127.0.0.1 root System lock TRUNCATE TABLE xxxx -------- FILE I/O -------- I/O thread 0 state: wait Windows aio (insert buffer thread) I/O thread 1 state: wait Windows aio (log thread) I/O thread 2 state: complete io for buf page (read thread) I/O thread 3 state: wait Windows aio (read thread) I/O thread 4 state: wait Windows aio (read thread) I/O thread 5 state: complete io for buf page (read thread) I/O thread 6 state: wait Windows aio (write thread) I/O thread 7 state: wait Windows aio (write thread) I/O thread 8 state: wait Windows aio (write thread) I/O thread 9 state: wait Windows aio (write thread) Pending normal aio reads: [2, 0, 0, 3] , aio writes: [0, 0, 0, 0] , ibuf aio reads:, log i/o's:, sync i/o's: Pending flushes (fsync) log: 0; buffer pool: 0 908141629 OS file reads, 8774070813 OS file writes, 2977363738 OS fsyncs 0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s ------------------------------------- INSERT BUFFER AND ADAPTIVE HASH INDEX ------------------------------------- InnoDB: ###### Diagnostic info printed to the standard error stream 2026-06-03T06:37:25.679003Z 0 [Warning] InnoDB: A long semaphore wait: --Thread 17216 has waited at btr0sea.ic line 128 for 258 seconds the semaphore: S-lock on RW-latch at 0000017F19122E18 created in file btr0sea.cc line 195 a writer (thread id 8340) has reserved it in mode wait exclusive number of readers 1, waiters flag 1, lock_word: ffffffff Last time read locked in file btr0sea.ic line 128 Last time write locked in file g:\ade\build\sb_0-34537258-1560180832.84\mysql-5.7.27\storage\innobase\include\btr0sea.ic line 90 2026-06-03T06:37:25.681739Z 0 [Warning] InnoDB: A long semaphore wait: --Thread 28160 has waited at btr0sea.ic line 128 for 241 seconds the semaphore: S-lock on RW-latch at 0000017F19123598 created in file btr0sea.cc line 195 a writer (thread id 13620) has reserved it in mode wait exclusive number of readers 1, waiters flag 1, lock_word: ffffffff Last time read locked in file btr0sea.ic line 128 Last time write locked in file G:\ade\build\sb_0-34537258-1560180832.84\mysql-5.7.27\storage\innobase\btr\btr0cur.cc line 3874 2026-06-03T06:37:25.684495Z 0 [Warning] InnoDB: A long semaphore wait: --Thread 23052 has waited at btr0sea.ic line 128 for 253 seconds the semaphore: S-lock on RW-latch at 0000017F19123598 created in file btr0sea.cc line 195 a writer (thread id 13620) has reserved it in mode wait exclusive number of readers 1, waiters flag 1, lock_word: ffffffff Last time read locked in file btr0sea.ic line 128 Last time write locked in file G:\ade\build\sb_0-34537258-1560180832.84\mysql-5.7.27\storage\innobase\btr\btr0cur.cc line 3874 2026-06-03T06:37:25.687586Z 0 [Warning] InnoDB: A long semaphore wait: --Thread 28480 has waited at btr0sea.ic line 128 for 272 seconds the semaphore: S-lock on RW-latch at 0000017F19122E18 created in file btr0sea.cc line 195 a writer (thread id 8340) has reserved it in mode wait exclusive number of readers 1, waiters flag 1, lock_word: ffffffff Last time read locked in file btr0sea.ic line 128 Last time write locked in file g:\ade\build\sb_0-34537258-1560180832.84\mysql-5.7.27\storage\innobase\include\btr0sea.ic line 90 2026-06-03T06:37:25.689857Z 0 [Warning] InnoDB: A long semaphore wait: --Thread 2868 has waited at buf0flu.cc line 1209 for 262 seconds the semaphore: SX-lock on RW-latch at 00000179B38E0DC0 created in file buf0buf.cc line 1460 a writer (thread id 1008) has reserved it in mode exclusive number of readers 0, waiters flag 1, lock_word: f0000000 Last time read locked in file ibuf0ibuf.cc line 4552 Last time write locked in file G:\ade\build\sb_0-34537258-1560180832.84\mysql-5.7.27\storage\innobase\ibuf\ibuf0ibuf.cc line 406 ………………………… 2026-06-03T06:37:56.919054Z 0 [Warning] InnoDB: A long semaphore wait: --Thread 13620 has waited at btr0sea.ic line 90 for 303 seconds the semaphore: X-lock (wait_ex) on RW-latch at 0000017F19123598 created in file btr0sea.cc line 195 a writer (thread id 13620) has reserved it in mode wait exclusive number of readers 1, waiters flag 1, lock_word: ffffffff Last time read locked in file btr0sea.ic line 128 Last time write locked in file G:\ade\build\sb_0-34537258-1560180832.84\mysql-5.7.27\storage\innobase\btr\btr0cur.cc line 3874 2026-06-03T06:37:56.921090Z 0 [Warning] InnoDB: A long semaphore wait: --Thread 24268 has waited at btr0sea.ic line 128 for 252 seconds the semaphore: S-lock on RW-latch at 0000017F19122E18 created in file btr0sea.cc line 195 a writer (thread id 8340) has reserved it in mode wait exclusive number of readers 1, waiters flag 1, lock_word: ffffffff Last time read locked in file btr0sea.ic line 128 Last time write locked in file g:\ade\build\sb_0-34537258-1560180832.84\mysql-5.7.27\storage\innobase\include\btr0sea.ic line 90 2026-06-03T06:37:56.923175Z 0 [Warning] InnoDB: A long semaphore wait: --Thread 15984 has waited at btr0sea.ic line 128 for 302 seconds the semaphore: S-lock on RW-latch at 0000017F19122CD8 created in file btr0sea.cc line 195 a writer (thread id 5420) has reserved it in mode wait exclusive number of readers 1, waiters flag 1, lock_word: ffffffff Last time read locked in file btr0sea.ic line 128 Last time write locked in file G:\ade\build\sb_0-34537258-1560180832.84\mysql-5.7.27\storage\innobase\btr\btr0cur.cc line 3874 InnoDB: ###### Starts InnoDB Monitor for 30 secs to print diagnostic info: InnoDB: Pending preads 0, pwrites 0 InnoDB: ###### Diagnostic info printed to the standard error stream 2026-06-03T07:04:50.616385Z 0 [Note] MySQL: Normal shutdown 2026-06-03T07:04:50.617251Z 0 [Note] Giving 97 client threads a chance to die gracefully 2026-06-03T07:54:31.982035Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details). 2026-06-03T07:54:31.983047Z 0 [Warning] 'NO_ZERO_DATE', 'NO_ZERO_IN_DATE' and 'ERROR_FOR_DIVISION_BY_ZERO' sql modes should be used with strict mode. They will be merged with strict mode in a future release. 2026-06-03T07:54:31.983057Z 0 [Warning] 'NO_AUTO_CREATE_USER' sql mode was not set. 2026-06-03T07:54:31.983098Z 0 [Note] --secure-file-priv is set to NULL. Operations related to importing and exporting data are disabled 2026-06-03T07:54:31.985272Z 0 [Note] MySQL (mysqld 5.7.27) starting as process 832 ... 2026-06-03T07:54:32.054771Z 0 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions 2026-06-03T07:54:32.055435Z 0 [Note] InnoDB: Uses event mutexes 2026-06-03T07:54:32.055728Z 0 [Note] InnoDB: _mm_lfence() and _mm_sfence() are used for memory barrier 2026-06-03T07:54:32.056143Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 2026-06-03T07:54:32.057581Z 0 [Note] InnoDB: Number of pools: 1 2026-06-03T07:54:32.058963Z 0 [Note] InnoDB: Not using CPU crc32 instructions 2026-06-03T07:54:32.063255Z 0 [Note] InnoDB: Initializing buffer pool, total size = 40G, instances = 8, chunk size = 128M 2026-06-03T07:54:34.619212Z 0 [Note] InnoDB: Completed initialization of buffer pool 2026-06-03T07:54:35.420695Z 0 [Note] InnoDB: Highest supported file format is Barracuda. 2026-06-03T07:54:36.121477Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 15319438590791 2026-06-03T07:54:36.449855Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 15319443833344 2026-06-03T07:54:36.847204Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 15319449076224 2026-06-03T07:54:37.263455Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 15319454319104 2026-06-03T07:54:37.544475Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 15319459561984 2026-06-03T07:54:37.678504Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 15319463095246 2026-06-03T07:54:37.681262Z 0 [Note] InnoDB: Database was not shutdown normally! 2026-06-03T07:54:37.681755Z 0 [Note] InnoDB: Starting crash recovery. 2026-06-03T07:54:38.088953Z 0 [Note] InnoDB: 2 transaction(s) which must be rolled back or cleaned up in total 1 row operations to undo 2026-06-03T07:54:38.089913Z 0 [Note] InnoDB: Trx id counter is 8424438528 2026-06-03T07:54:38.090288Z 0 [Note] InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 …… 91 92 93 94 95 96 97 98 99 2026-06-03T07:54:42.043861Z 0 [Note] InnoDB: Apply batch completed 2026-06-03T07:54:42.295726Z 0 [Note] InnoDB: Rolling back trx with id 8424429306, 0 rows to undo 2026-06-03T07:54:42.298212Z 0 [Note] InnoDB: Rollback of trx with id 8424429306 completed 2026-06-03T07:55:19.432722Z 0 [Note] InnoDB: Completing truncate for table with id (8714) residing in file-per-table tablespace with id (6005) 2026-06-03T07:55:30.963664Z 0 [ERROR] InnoDB: The age of the last checkpoint is 90593936, which exceeds the log group capacity 90593280. 2026-06-03T07:55:47.442228Z 0 [ERROR] InnoDB: The age of the last checkpoint is 90602582, which exceeds the log group capacity 90593280. 2026-06-03T07:56:05.422243Z 0 [ERROR] InnoDB: The age of the last checkpoint is 90609452, which exceeds the log group capacity 90593280. 2026-06-03T07:56:27.643550Z 0 [ERROR] InnoDB: The age of the last checkpoint is 90621740, which exceeds the log group capacity 90593280. 2026-06-03T07:56:47.845714Z 0 [ERROR] InnoDB: The age of the last checkpoint is 90627886, which exceeds the log group capacity 90593280. 2026-06-03T07:57:04.714691Z 0 [ERROR] InnoDB: The age of the last checkpoint is 90639662, which exceeds the log group capacity 90593280. 2026-06-03T07:57:26.028889Z 0 [ERROR] InnoDB: The age of the last checkpoint is 90645808, which exceeds the log group capacity 90593280. 2026-06-03T07:57:42.796901Z 0 [ERROR] InnoDB: The age of the last checkpoint is 90655262, which exceeds the log group capacity 90593280. 2026-06-03T07:58:04.513110Z 0 [ERROR] InnoDB: The age of the last checkpoint is 90670384, which exceeds the log group capacity 90593280. 2026-06-03T07:58:20.675070Z 0 [ERROR] InnoDB: The age of the last checkpoint is 90689842, which exceeds the log group capacity 90593280. 2026-06-03T07:58:39.362158Z 0 [ERROR] InnoDB: The age of the last checkpoint is 90699949, which exceeds the log group capacity 90593280. 2026-06-03T07:58:57.146181Z 0 [ERROR] InnoDB: The age of the last checkpoint is 90707243, which exceeds the log group capacity 90593280. 2026-06-03T07:59:15.226281Z 0 [ERROR] InnoDB: The age of the last checkpoint is 90731065, which exceeds the log group capacity 90593280. 2026-06-03T07:59:32.902269Z 0 [ERROR] InnoDB: The age of the last checkpoint is 90751406, which exceeds the log group capacity 90593280. 2026-06-03T07:59:55.020833Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details). 2026-06-03T07:59:55.022839Z 0 [Warning] 'NO_ZERO_DATE', 'NO_ZERO_IN_DATE' and 'ERROR_FOR_DIVISION_BY_ZERO' sql modes should be used with strict mode. They will be merged with strict mode in a future release. 2026-06-03T07:59:55.022856Z 0 [Warning] 'NO_AUTO_CREATE_USER' sql mode was not set. 2026-06-03T07:59:55.022918Z 0 [Note] --secure-file-priv is set to NULL. Operations related to importing and exporting data are disabled 2026-06-03T07:59:55.028372Z 0 [Note] MySQL (mysqld 5.7.27) starting as process 2532 ... 2026-06-03T07:59:55.078201Z 0 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions 2026-06-03T07:59:55.078998Z 0 [Note] InnoDB: Uses event mutexes 2026-06-03T07:59:55.079491Z 0 [Note] InnoDB: _mm_lfence() and _mm_sfence() are used for memory barrier 2026-06-03T07:59:55.080092Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 2026-06-03T07:59:55.084872Z 0 [Note] InnoDB: Number of pools: 1 2026-06-03T07:59:55.090793Z 0 [Note] InnoDB: Not using CPU crc32 instructions 2026-06-03T07:59:55.096910Z 0 [Note] InnoDB: Initializing buffer pool, total size = 40G, instances = 8, chunk size = 128M 2026-06-03T07:59:57.966267Z 0 [Note] InnoDB: Completed initialization of buffer pool 2026-06-03T07:59:58.778551Z 0 [Note] InnoDB: Highest supported file format is Barracuda. 2026-06-03T07:59:59.348188Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 15319447826657 2026-06-03T07:59:59.942491Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 15319453069312 2026-06-03T08:00:00.233703Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 15319458312192 2026-06-03T08:00:00.470153Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 15319463555072 2026-06-03T08:00:01.158338Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 15319468797952 2026-06-03T08:00:01.852263Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 15319474040832 2026-06-03T08:00:02.555075Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 15319479283712 2026-06-03T08:00:03.289043Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 15319484526592 2026-06-03T08:00:04.031381Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 15319489769472 2026-06-03T08:00:04.754714Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 15319495012352 2026-06-03T08:00:05.533650Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 15319500255232 2026-06-03T08:00:06.253542Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 15319505498112 2026-06-03T08:00:06.883691Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 15319510740992 2026-06-03T08:00:07.603988Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 15319515983872 2026-06-03T08:00:08.268531Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 15319521226752 2026-06-03T08:00:08.967662Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 15319526469632 2026-06-03T08:00:09.323566Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 15319529184727 2026-06-03T08:00:09.328240Z 0 [Note] InnoDB: Database was not shutdown normally! 2026-06-03T08:00:09.328844Z 0 [Note] InnoDB: Starting crash recovery. 2026-06-03T08:00:09.730171Z 0 [Note] InnoDB: 1 transaction(s) which must be rolled back or cleaned up in total 1 row operations to undo 2026-06-03T08:00:09.731034Z 0 [Note] InnoDB: Trx id counter is 8424439040 2026-06-03T08:00:09.731402Z 0 [Note] InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 …… 94 95 96 97 98 99 2026-06-03T08:00:17.587182Z 0 [Note] InnoDB: Apply batch completed 2026-06-03T08:01:02.988241Z 0 [Note] InnoDB: Completing truncate for table with id (8714) residing in file-per-table tablespace with id (6005) 2026-06-03T08:01:07.965314Z 0 [ERROR] InnoDB: The age of the last checkpoint is 90593580, which exceeds the log group capacity 90593280. 2026-06-03T08:01:25.945332Z 0 [ERROR] InnoDB: The age of the last checkpoint is 90599727, which exceeds the log group capacity 90593280. 2026-06-03T08:01:43.117294Z 0 [ERROR] InnoDB: The age of the last checkpoint is 90610481, which exceeds the log group capacity 90593280. 2026-06-03T08:02:05.338558Z 0 [ERROR] InnoDB: The age of the last checkpoint is 90622769, which exceeds the log group capacity 90593280.
从这里看,最初是truncate table xxxx,然后由于被阻塞了无法truncate成功,可以就关闭了mysql服务,然后启动库就没有成功,然后就是加上了innodb_force_recovery出现了上述截图的错误.尝试进行强制拉库,遭遇以下错误
2026-06-04T07:05:59.924315Z 0 [Note] MySQL (mysqld 5.7.27) starting as process 8764 ... 2026-06-04T07:05:59.944187Z 0 [Warning] option 'innodb-purge-threads': unsigned value 0 adjusted to 1 2026-06-04T07:05:59.947611Z 0 [Note] InnoDB: Started in read only mode 2026-06-04T07:05:59.948012Z 0 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions 2026-06-04T07:05:59.948485Z 0 [Note] InnoDB: Uses event mutexes 2026-06-04T07:05:59.948825Z 0 [Note] InnoDB: _mm_lfence() and _mm_sfence() are used for memory barrier 2026-06-04T07:05:59.949329Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 2026-06-04T07:05:59.950087Z 0 [Note] InnoDB: Number of pools: 1 2026-06-04T07:05:59.950587Z 0 [Note] InnoDB: Not using CPU crc32 instructions 2026-06-04T07:05:59.950987Z 0 [Note] InnoDB: Disabling background log and ibuf IO write threads. 2026-06-04T07:05:59.952835Z 0 [Note] InnoDB: Initializing buffer pool, total size = 512M, instances = 1, chunk size = 128M 2026-06-04T07:05:59.980631Z 0 [Note] InnoDB: Completed initialization of buffer pool 2026-06-04T07:06:00.012856Z 0 [Note] InnoDB: Highest supported file format is Barracuda. 2026-06-04T07:06:00.013649Z 0 [Note] InnoDB: The user has set SRV_FORCE_NO_LOG_REDO on, skipping log redo 2026-06-04T07:06:00.019299Z 0 [Note] InnoDB: Completing truncate for table with id (8714) residing in file-per-table tablespace with id (6005) 07:06:00 UTC - mysqld got exception 0xc0000005 ; 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. Attempting to collect some information that could help diagnose the problem. As this is a crash and something is definitely wrong, the information collection process might fail. key_buffer_size=8388608 read_buffer_size=131072 max_used_connections=0 max_threads=200 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 = 87429 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... 7ff67eaba97e mysqld.exe!std::operator<<<std::char_traits<char> >()[ostream:791] 7ff67f1ffd49 mysqld.exe!os_file_create_subdirs_if_needed()[os0file.cc:2013] 7ff67f22e967 mysqld.exe!fil_ibd_create()[fil0fil.cc:3530] 7ff67f2afdd7 mysqld.exe!truncate_t::fixup_tables_in_non_system_tablespace()[row0trunc.cc:2274] 7ff67f1c563a mysqld.exe!innobase_start_or_create_for_mysql()[srv0start.cc:2346] 7ff67f12ea40 mysqld.exe!innobase_init()[ha_innodb.cc:4077] 7ff67e9b783e mysqld.exe!ha_initialize_handlerton()[handler.cc:840] 7ff67eab7228 mysqld.exe!plugin_initialize()[sql_plugin.cc:1229] 7ff67eab8790 mysqld.exe!plugin_register_builtin_and_init_core_se()[sql_plugin.cc:1589] 7ff67e972de3 mysqld.exe!init_server_components()[mysqld.cc:4080] 7ff67e977da5 mysqld.exe!win_main()[mysqld.cc:4773] 7ff67e975705 mysqld.exe!mysql_service()[mysqld.cc:5226] 7ff80e734da7 MSVCR120.dll!_beginthread() 7ff80e734e60 MSVCR120.dll!_endthread() 7ff84e4d84d4 KERNEL32.DLL!BaseThreadInitThunk() 7ff850cb1791 ntdll.dll!RtlUserThreadStart() 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.
在启动过程中需要去完成truncate操作,但是由于强制拉库是只读状态导致无法完成,直接启动失败.如果非只读状态拉库,启动过程包InnoDB: Corruption of an index tree: table `innodb_change_buffer` index `CLUST_IND`, father ptr page no 111415, child page no 517749异常
2026-06-04T13:35:46.447160Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery. 2026-06-04T13:35:46.448525Z 0 [ERROR] InnoDB: Corruption of an index tree: table `innodb_change_buffer` index `CLUST_IND`, father ptr page no 111415, child page no 517749 PHYSICAL RECORD: n_fields 6; 1-byte offsets; info bits 0 0: len 4; hex 00001775; asc u;; 1: len 1; hex 00; asc ;; 2: len 4; hex 00e78555; asc U;; 3: len 16; hex 000400010c0f0190002d860800088000; asc - ;; 4: len 29; hex 323032362d30332d31345f3132325f315f323032363033313432303136; asc 2026-03-14_122_1_202603142016;; 5: len 8; hex 800000001b26cad6; asc & ;; 2026-06-04T13:35:46.450738Z 0 [Note] InnoDB: n_owned: 0; heap_no: 2; next rec: 211 PHYSICAL RECORD: n_fields 7; 1-byte offsets; info bits 0 0: len 4; hex 00001775; asc u;; 1: len 1; hex 00; asc ;; 2: len 4; hex 00e78555; asc U;; 3: len 16; hex 000400010c0f0190002d860800088000; asc - ;; 4: len 29; hex 323032362d30332d31345f3132325f315f323032363033313432303136; asc 2026-03-14_122_1_202603142016;; 5: len 8; hex 800000001b26cad6; asc & ;; 6: len 4; hex 0001b337; asc 7;; 2026-06-04T13:35:46.452647Z 0 [Note] InnoDB: n_owned: 0; heap_no: 147; next rec: 14554 2026-06-04T13:35:46.453038Z 0 [ERROR] [FATAL] InnoDB: You should dump + drop + reimport the table to fix the corruption. If the crash happens at database startup. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery. Then dump + drop + reimport. 2026-06-04 21:35:46 0x828 InnoDB: Assertion failure in thread 2088 in file ut0ut.cc line 910 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.7/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 13:35:46 UTC - mysqld got exception 0x80000003 ; 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. Attempting to collect some information that could help diagnose the problem. As this is a crash and something is definitely wrong, the information collection process might fail. key_buffer_size=8388608 read_buffer_size=131072 max_used_connections=0 max_threads=200 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 = 87429 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... 7ff7c7794312 mysqld.exe!my_sigabrt_handler()[my_thr_init.c:449] 7fffaf31ec9d MSVCR120.dll!raise() 7fffaf324874 MSVCR120.dll!abort() 7ff7c78b07e4 mysqld.exe!ut_dbg_assertion_failed()[ut0dbg.cc:67] 7ff7c78b09c1 mysqld.exe!ib::fatal::~fatal()[ut0ut.cc:910] 7ff7c790a794 mysqld.exe!btr_page_get_father_node_ptr_func()[btr0btr.cc:799] 7ff7c790a28e mysqld.exe!btr_page_get_father()[btr0btr.cc:854] 7ff7c7906cca mysqld.exe!btr_compress()[btr0btr.cc:3577] 7ff7c7913a3e mysqld.exe!btr_cur_compress_if_useful()[btr0cur.cc:5068] 7ff7c7917f7c mysqld.exe!btr_cur_pessimistic_delete()[btr0cur.cc:5403] 7ff7c79583f9 mysqld.exe!ibuf_delete_rec()[ibuf0ibuf.cc:4385] 7ff7c795805e mysqld.exe!ibuf_delete_for_discarded_space()[ibuf0ibuf.cc:4833] 7ff7c78d51a8 mysqld.exe!fil_recreate_tablespace()[fil0fil.cc:2265] 7ff7c794fe06 mysqld.exe!truncate_t::fixup_tables_in_non_system_tablespace()[row0trunc.cc:2297] 7ff7c786563a mysqld.exe!innobase_start_or_create_for_mysql()[srv0start.cc:2346] 7ff7c77cea40 mysqld.exe!innobase_init()[ha_innodb.cc:4077] 7ff7c705783e mysqld.exe!ha_initialize_handlerton()[handler.cc:840] 7ff7c7157228 mysqld.exe!plugin_initialize()[sql_plugin.cc:1229] 7ff7c7158790 mysqld.exe!plugin_register_builtin_and_init_core_se()[sql_plugin.cc:1589] 7ff7c7012de3 mysqld.exe!init_server_components()[mysqld.cc:4080] 7ff7c7017da5 mysqld.exe!win_main()[mysqld.cc:4773] 7ff7c7015705 mysqld.exe!mysql_service()[mysqld.cc:5226] 7fffaf2d4da7 MSVCR120.dll!_beginthread() 7fffaf2d4e60 MSVCR120.dll!_endthread() 7fffd0f784d4 KERNEL32.DLL!BaseThreadInitThunk() 7fffd3b91791 ntdll.dll!RtlUserThreadStart() 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.
基于这种两种情况:
2026-06-04T13:35:46.448525Z 0 [ERROR] InnoDB: Corruption of an index tree: table `innodb_change_buffer` index `CLUST_IND`, father ptr page no 111415, child page no 517749和InnoDB: Completing truncate for table with id (8714) residing in file-per-table tablespace with id (6005)异常形成了相互死循环,无法直接强制拉库.
这个库有1.5T如果通过工具提取效率有点低

对于这样的情况,使用ibd的discard+import功能进行处理,参考相关文章:
frm和ibd文件数据库恢复
运气不错,这个客户的所有库通过这种方法导入ibd文件(部分temp结尾的临时表数据可以不用恢复,占据空间较大)之后,然后通过mysqldump顺利导出所有数据,完成本次恢复任务

mysql drop database 恢复思路
今天有一个客户在在虚拟机环境中使用drop database删除一个业务mysql的库,删除之后,第一时间关闭了该虚拟机系统.接到该case请求之后,让客户提供了虚拟机文件(vmdk),通过工具分析,mysql数据库是放在/分区下面的/data里面(lvm结构,xfs文件系统),但是已经看不到他们删除的数据库(mysql一个库对应一个目录)

对于这种情况,我们第一步尝试文件系统层面反删除恢复(对数据库所在分区进行文件系统层面扫描,尝试恢复被删除的mysql表文件),运气不错,找到了一些被删除库的ibd文件

对于这些文件,选择出来客户需要的表,采用discard+import方式进行恢复,类似命令
alter table tablename discard tablespace; alter table tablename import tablespace;
对于有些部分block损坏的ibd文件,直接这样操作可能会报Data structure corruption错误,这样的情况,可以通过工具解析ibd文件进行恢复

对于有些表,可能在文件系统层面反删除无法恢复,我们通过对磁盘进行mysql的数据块层面扫描(识别在磁盘上没有覆盖的mysql的block),按照pageid的方式进行重组成一个个page文件

然后基于这些page进行恢复需要的表数据

基本上通过上述的方法实现最大限度mysql删除数据的恢复(比如drop database,drop table,truncate table)
如果MySQL数据库恢复问题,需要专业恢复技术支持,请联系我们提供专业MySql数据库恢复服务:
电话/微信:17813235971 Q Q:107644445
E-Mail:dba@xifenfei.com
应用连接错误,初始化mysql数据库恢复
有人在部署一个新网站的时候,写错了配置信息,直接导致原有数据库被清掉,并创建了新库和写入了数据(其实本质就是drop table恢复)

登录操作系统查看,发现数据库文件在根分区,创建了新库,写入了数据之外,还有几个G的binlog.全部恢复不太可能,最后客户决定需要恢复的2个核心表数据,估计也就几十M的数据.通过os层面进行分析,发现操作系统的反删除恢复无法实现这类数据恢复.最后决定从mysql innodb的的碎片级别记性扫描恢复,通过扫描发现较多碎片

然后通过一些思路找出来需要恢复的表对应的page文件,然后对其进行解析恢复出来需要的数据

具体技术文章参考:
kettle导致MySQL数据丢失恢复
[MySQL异常恢复]恢复数据字典表讲解
[MySQL异常恢复]mysql drop table 数据恢复
[MySQL异常恢复]使用工具直接抽取MySQL数据字典
MySQL drop database恢复(恢复方法同样适用MySQL drop table,delete,truncate table)

加我微信(17813235971)
加我QQ(107644445)

