mysql无法启动,Error: page 13476 log sequence number xxxx

最新推荐文章于 2024-04-13 11:25:20 发布
原创 最新推荐文章于 2024-04-13 11:25:20 发布 · 7.6k 阅读 · 3 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#mysql #linux运维

本文介绍了一种因Error:page13476logsequencenumber导致MySQL无法启动的情况及其解决办法，通过调整innodb_force_recovery参数成功启动，并介绍了如何导出及重新导入数据库的方法。

1、服务器状况，mysql无法启动，日志提示Error: page 13476 log sequence number

2、使用service mysql start命令启动mysql失败

3、查询mysql的日志文件localhost.localdomain.err,提示Error: page 13476 log sequence number 50961222223

4、查询资料和解决办法

5、编辑mysql的配置文件my.cnf，添加innodb_force_recovery属性

设置 innodb_force_recovery = 1，然后保存修改，执行service mysql start命令，启动mysql

innodb_force_recovery = 1不行就改成2,2不行改成3，以此类推，最大值为6，

我是在innodb_force_recovery = 3时启动成功的

6、导出数据库中的数据

7、删除数据库

8、将my.cnf中的innodb_force_recovery 属性改为0，innodb_force_recovery = 0，或者删掉这个属于

9、重启mysql数据库

10、新建数据库，将导出的数据再导入进去即可（也可以重装mysql然后导入数据）


【檀越剑指大厂--mysql】mysql高阶篇
优快云站内信: https://i.youkuaiyun.com/#/msg/chat/qyj19920704
08-17 1万+
为了避免发生数据丢失的问题，当前事务数据库系统普遍都采用了Write Ahead log策略即当事务提交时，先写重做日志，再修改页。当由干发生宕机而导致数据丢失时，通过重做日志来完成数据的恢复。这也是事务ACID中D(Durability持久性)的要求。checkpoint的作用缩短数据库的恢复时间;缓冲池不够用时，将脏页刷新到磁盘;Lru列表不够用时,强制刷新脏页重做日志不可用时，刷新脏页。对于InnoDB存储引擎而言，其是通过LSN(LogSequence Number)来标记版本的。.........
Python全栈（五）Web安全攻防之7.MySQL注入读写文件和HTTP头中的SQL注入
CUFEECR的博客
03-10 4668
pikachu是一个比较详细的漏洞平台；MySQL读取文件用load_file()函数；写入文件用into outfile。UPDATEXML()函数用于捕捉错误；在user-agent后加入payload进行user-agent注入；通过修改请求头中的referer进行SQL注入测试，可以通过3种方式进行安全测试；在请求头的cookie参数中加入payload‘进行cookie测试；使用Base64加密的注入语句，插入到Cookie对应的位置完成SQL注入漏洞的探测。
mysql无法启动,Error: page 13476 log sequence number
weixin_30323961的博客
09-16 754
1、服务器状况，mysql无法启动，日志提示Error: page 13476 log sequence number 2、使用service mysql start命令启动mysql失败 3、查询mysql的日志文件localhost.localdomain.err,提示Error: page 13476 log sequence number 50961222223 ...
mysql 运行异常：InnoDB: Error: page xxx log sequence number xx xxx InnoDB: is in the future!
gyf651194544的博客
10-08 2106
例如：mysqldump -uclear -p123456 clear_prison > clear_prison.sql。4.然后重启数据库，重启后可以看下数据库mysql的日志。5.修改上面第二步中的配置文件，将 数值6改为0，然后报错退出，然后重启数据库mysql。mysqldump -u 用户名 -p 密码 数据库名 > xxx.sql。6.将之前备份的数据库文件重新导入到数据库中。然后重启数据库（这个时候数据库是只读状态）1. 先将自己得数据库进行备份。2.配置参数进行数据库得修复。
centos7的mysql启动不了：log sequence number 2710184143 is in the future! Current system log sequence numbe
qq_40351360的博客
10-13 1121
centos7的mysql启动不了：log sequence number 2710184143 is in the future! Current system log sequence numbe
MySQL常见报错_innodb error page 4 log sequence number 48269927
2401_84253894的博客
04-13 859
体系化！**
2025-12-19T05:34:37.849417Z 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. 2025-12-19T05:34:37.849496Z 0 [Note] --secure-file-priv is set to NULL. Operations related to importing and exporting data are disabled 2025-12-19T05:34:37.849866Z 0 [Note] C:\BtSoft\mysql\MySQL5.7\bin\mysqld.exe (mysqld 5.7.38-log) starting as process 8348 ... 2025-12-19T05:34:37.868526Z 0 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions 2025-12-19T05:34:37.869014Z 0 [Note] InnoDB: Uses event mutexes 2025-12-19T05:34:37.869267Z 0 [Note] InnoDB: _mm_lfence() and _mm_sfence() are used for memory barrier 2025-12-19T05:34:37.869618Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 2025-12-19T05:34:37.870357Z 0 [Note] InnoDB: Number of pools: 1 2025-12-19T05:34:37.870807Z 0 [Note] InnoDB: Not using CPU crc32 instructions 2025-12-19T05:34:37.873342Z 0 [Note] InnoDB: Initializing buffer pool, total size = 256M, instances = 1, chunk size = 128M 2025-12-19T05:34:37.890813Z 0 [Note] InnoDB: Completed initialization of buffer pool 2025-12-19T05:34:37.928888Z 0 [Note] InnoDB: Highest supported file format is Barracuda. 2025-12-19T05:34:37.935781Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 47795629696 2025-12-19T05:34:37.936452Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 47795678803 2025-12-19T05:34:37.956276Z 0 [Note] InnoDB: Database was not shutdown normally! 2025-12-19T05:34:37.956614Z 0 [Note] InnoDB: Starting crash recovery. 2025-12-19T05:34:38.334975Z 0 [Note] InnoDB: 1 transaction(s) which must be rolled back or cleaned up in total 0 row operations to undo 2025-12-19T05:34:38.335541Z 0 [Note] InnoDB: Trx id counter is 101645056 2025-12-19T05:34:38.336142Z 0 [Note] InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 2025-12-19T05:34:38.853689Z 0 [Note] InnoDB: Apply batch completed 2025-12-19T05:34:38.854109Z 0 [Note] InnoDB: Last MySQL binlog file position 0 55386, file name mysql-bin.000051 2025-12-19T05:34:38.961866Z 0 [Note] InnoDB: Cleaning up trx with id 101609997 2025-12-19T05:34:39.294080Z 0 [ERROR] InnoDB: In file '.\20251107_092631\auth.ibd', tablespace id and flags are 828 and 33, but in the InnoDB data dictionary they are 122 and 33. Have you moved InnoDB .ibd files around without using the commands DISCARD TABLESPACE and IMPORT TABLESPACE? Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting-datadict.html for how to resolve the issue. 2025-12-19T05:34:39.295376Z 0 [ERROR] InnoDB: Operating system error number 203 in a file operation. 2025-12-19T05:34:39.295740Z 0 [Note] InnoDB: Some operating system error numbers are described at http://dev.mysql.com/doc/refman/5.7/en/operating-system-error-codes.html 2025-12-19T05:34:39.296279Z 0 [ERROR] InnoDB: Could not find a valid tablespace file for `20251107_092631/auth`. Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting-datadict.html for how to resolve the issue. 2025-12-19T05:34:39.296984Z 0 [Warning] InnoDB: Ignoring tablespace `20251107_092631/auth` because it could not be opened. 2025-12-19T05:34:39.379037Z 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1" 2025-12-19T05:34:39.379567Z 0 [Note] InnoDB: Creating shared tablespace for temporary tables 2025-12-19T05:34:39.380394Z 0 [Note] InnoDB: Setting file 'D:\MySQL\Data\ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... 2025-12-19T05:34:39.435030Z 0 [Note] InnoDB: File 'D:\MySQL\Data\ibtmp1' size is now 12 MB. 2025-12-19T05:34:39.455825Z 0 [Note] InnoDB: 96 redo rollback segment(s) found. 96 redo rollback segment(s) are active. 2025-12-19T05:34:39.456485Z 0 [Note] InnoDB: 32 non-redo rollback segment(s) are active. 2025-12-19T05:34:39.457305Z 0 [Note] InnoDB: Waiting for purge to start 2025-12-19T05:34:39.509818Z 0 [Note] InnoDB: 5.7.38 started; log sequence number 47795678803 2025-12-19T05:34:39.510836Z 0 [Note] Plugin 'FEDERATED' is disabled. 2025-12-19T05:34:39.514400Z 0 [Note] InnoDB: Loading buffer pool(s) from D:\MySQL\Data\ib_buffer_pool 2025-12-19T05:34:39.522762Z 0 [Note] Recovering after a crash using mysql-bin 2025-12-19T05:34:39.523590Z 0 [Note] Starting crash recovery... 2025-12-19T05:34:39.523929Z 0 [Note] Crash recovery finished. 2025-12-19T05:34:39.569369Z 0 [Note] Found ca.pem, server-cert.pem and server-key.pem in data directory. Trying to enable SSL support using them. 2025-12-19T05:34:39.569953Z 0 [Note] Skipping generation of SSL certificates as certificate files are present in data directory. 2025-12-19T05:34:39.570390Z 0 [Warning] A deprecated TLS version TLSv1 is enabled. Please use TLSv1.2 or higher. 2025-12-19T05:34:39.570890Z 0 [Warning] A deprecated TLS version TLSv1.1 is enabled. Please use TLSv1.2 or higher. 2025-12-19T05:34:39.572758Z 0 [Warning] CA certificate ca.pem is self signed. 2025-12-19T05:34:39.573483Z 0 [Note] Skipping generation of RSA key pair as key files are present in data directory. 2025-12-19T05:34:39.574195Z 0 [Note] Server hostname (bind-address): '*'; port: 3306 2025-12-19T05:34:39.574741Z 0 [Note] IPv6 is available. 2025-12-19T05:34:39.575017Z 0 [Note] - '::' resolves to '::'; 2025-12-19T05:34:39.575349Z 0 [Note] Server socket created on IP: '::'. 2025-12-19T05:34:39.604561Z 0 [Note] Failed to start slave threads for channel '' 2025-12-19T05:34:39.619077Z 0 [ERROR] InnoDB: Page [page id: space=572, page number=3] log sequence number 47818895373 is in the future! Current system log sequence number 47795679298. 2025-12-19T05:34:39.619873Z 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. 2025-12-19T05:34:39.633764Z 0 [Note] Event Scheduler: Loaded 0 events 2025-12-19T05:34:39.634297Z 0 [Note] C:\BtSoft\mysql\MySQL5.7\bin\mysqld.exe: ready for connections. Version: '5.7.38-log' socket: '' port: 3306 MySQL Community Server (GPL) 2025-12-19 13:34:42 0x5d18 InnoDB: Assertion failure in thread 23832 in file fsp0fsp.cc line 3880 InnoDB: Failing assertion: xdes_mtr_get_bit(descr, XDES_FREE_BIT, header_page % FSP_EXTENT_SIZE, mtr) == FALSE 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. 05:34:42 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=134217728 read_buffer_size=131072 max_used_connections=4 max_threads=300 thread_count=4 connection_count=4 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 403530 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x23a27e14790 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... 7ff63abcb302 mysqld.exe!my_errno() 7ffc6838ee1d MSVCR120.dll!raise() 7ffc68394a14 MSVCR120.dll!abort() 7ff63ace7434 mysqld.exe!?reserve@?$vector@EV?$allocator@E@std@@@std@@QEAAX_K@Z() 7ff63acfab30 mysqld.exe!?reserve@?$vector@EV?$allocator@E@std@@@std@@QEAAX_K@Z() 7ff63ac64cdf mysqld.exe!?reserve@?$vector@EV?$allocator@E@std@@@std@@QEAAX_K@Z() 7ff63ac673e6 mysqld.exe!?reserve@?$vector@EV?$allocator@E@std@@@std@@QEAAX_K@Z() 7ff63ac66f29 mysqld.exe!?reserve@?$vector@EV?$allocator@E@std@@@std@@QEAAX_K@Z() 7ff63ac63e9a mysqld.exe!?reserve@?$vector@EV?$allocator@E@std@@@std@@QEAAX_K@Z() 7ff63ac2a36e mysqld.exe!?reserve@?$vector@EV?$allocator@E@std@@@std@@QEAAX_K@Z() 7ff63ac2e5ac mysqld.exe!?reserve@?$vector@EV?$allocator@E@std@@@std@@QEAAX_K@Z() 7ffc7f294cb0 KERNEL32.DLL!BaseThreadInitThunk() 7ffc8077edcb ntdll.dll!RtlUserThreadStart() Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0): Connection ID (thread ID): 0 Status: NOT_KILLED 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. 2025-12-19T05:34:42.715725Z 0 [Note] InnoDB: Buffer pool(s) load completed at 251219 13:34:42
最新发布
12-20
- `InnoDB: Error: space id and page n:XXXX ...`（表空间ID不匹配） - `InnoDB: Operating system error number XX`（操作系统错误，如文件权限或磁盘问题） - `InnoDB: Log sequence number is in the future`...
prometheus 监控mysql数据库
m0_67401746的博客
08-02 1556
本文通过prometheus来监控mysql数据库状态，主要利用mysqld_exporter来实现mysql状态上报。主机信息如下主机IP用途mysql数据库prometheus监控主机grafana。
记录——Mybatis批量更新死锁问题
banmajio的博客
05-10 3204
Mysql批量更新死锁问题
MySQL日志序列号 - LSN
weixin_39997438的博客
08-01 2491
概要 LSN（log sequence number）：日志序列号，是一个一直递增的整形数字，在MySQL5.6.3版本后占8个字节。它表示事务写入到日志的字节总量。LSN主要用于发生crash时对数据进行recovery！每个数据页、重做日志、checkpoint都有LSN。 LSN不仅存在于重做日志中，在每个数据页头部也会有对应的LSN号。在数据页头部，LSN记录当前页最后一次修改的LSN号，用于在recovery时对比重做日志LSN号决定是否对该页进行恢复数据。checkpoint也是有LSN号记录
MySQL中LSN介绍（日志序列号）
学亮编程手记
03-27 3141
MySQL中的LSN（Log Sequence Number，日志序列号）是一个核心概念，特别是在使用InnoDB存储引擎的情况下。LSN是数据库内部用于跟踪事务日志（redo log）中各个记录位置的唯一标识符。它是InnoDB用于保证数据一致性、支持崩溃恢复、实现多版本并发控制（MVCC）以及进行日志管理的重要工具。
强制InnoDB恢复log sequence number is in the future
每天都要开心呀(#^.^#)
09-23 3401
重启docker发现docker-compose部署的mysql无法启动问题解决办法
Redo日志 (4)—log sequence number（六十二)
ke1ying的博客
10-11 505
前面说了redo日志的格式，刷新到磁盘后台有线程每秒运行一次，还有事务提交的时候，buffer pool不会刷新到磁盘，但是log buffer会刷新到磁盘。Log buffer会分成若干的block，吧这些block持久化到磁盘上，mysql根目录有两个log_file0和log_file1,可以增加，当存满的时候，从0循环继续存储，默认是48Mb。每个block是512个字节，前面四个block占比2048个字节是记录管理信息，2048字节后面开始记录block。 redo日志文件格式(3)—mysq
mysql innodb 修复_关于mysql的innodb无法启动修复的问题
weixin_30580403的博客
01-27 2070
我启用了innodb_force_recovery = 1对mysql数据库进行损坏修复.但是mysql很不给面子,CPU一直在吃,但是就是不给我启动...导致我无法导出,并回复数据,请问目前如何是好呢下面是错误的log140718 22:22:34 [Note] Plugin 'FEDERATED' is disabled.140718 22:22:34 InnoDB: The InnoDB m...
mysql innodb引擎表（日志表）损坏的解决办法
oThrowsException的博客
09-14 5775
今天干了一件事：mysql 把一台5.5版本的data目录文件移到另一台 到5.7版本下，重避mysql后启动报下面错 [ ERROR] InnoDB: Page [page id: space=0, page number=245792] log sequence number 20578013 is in the future! Current system log sequence number 14487872. 网上百度了跟损坏有关 解决办法： 需要跳过恢复步骤，修改my.cnf文件，在my.cn
InnoDB: The log sequence number in ibdatafiles does not match the log sequence number in the ib_log
雅冰石的专栏
07-06 5277
今天做将主库的物理备份恢复到从库的实验时，报错： [root@slave2 mysql]# service mysql restart  ERROR! MySQL server PID file could not befound! Starting MySQL.. ERROR! The server quitwithout updating PID file (/mysql_data1/m
mysql数据损坏修复(InnoDB: Error: page 5 log sequence number 836321191877)
weixin_49674445的博客
11-23 5471
2021-11-18 10:56:14 7fcd38b3b780 InnoDB: Error: page 5 log sequence number 836321191877 InnoDB: is in the future! Current system log sequence number 836321150789. InnoDB: Your database may be corrupt or you may have copied the InnoDB
MySQL启动失败，提示“InnoDB: Error: page 11 log sequence number 347094373723”
bigwood99的博客
09-29 2576
前天作了一次模拟停电，服务期自动监测关机试验。 试验很成功，但是有个缺陷，关机前未正常关闭，运行的mysql服务。悲剧来了，服务器重起后，mysql服务启动失败。
D:\mysql5>"D:\mysql5\bin\mysqld" --defaults-file="D:\mysql5\my.ini" --console 250720 13:30:08 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 250720 13:30:08 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 176188313. InnoDB: Doing recovery: scanned up to log sequence number 0 176188313 InnoDB: Last MySQL binlog file position 0 0, file name 250720 13:30:08 InnoDB: Started; log sequence number 0 176188313 250720 13:30:08 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist
07-21
### 问题分析 MySQL 启动时提示 `Can't open and lock privilege tables: Table 'mysql.host' doesn't exist`，通常表示 MySQL 无法访问或初始化其系统权限表。这类问题常见于新安装的 MySQL 实例、数据目录被手动删除或迁移后未正确初始化的情况。权限表如 `mysql.user`、`mysql.host` 是 MySQL 服务器运行的基础，用于管理用户权限和访问控制。当这些表缺失或损坏时，MySQL 服务将无法正常启动[^1]。 --- ### 解决方法 #### 1. 使用 `mysql_install_db` 初始化系统表 对于基于 Linux 的系统，若 MySQL 数据目录未正确初始化，可使用 `mysql_install_db` 工具来创建系统表： ```bash mysql_install_db --basedir=/usr/local/mysql --datadir=/var/lib/mysql ``` 该命令将生成 `mysql.user`、`mysql.host` 等系统表，确保 MySQL 服务可以正常启动和运行[^1]。 #### 2. 使用 `--initialize` 初始化数据目录（适用于 MySQL 5.7 及以上） 若使用的是 MySQL 5.7.6 或更高版本，推荐使用 `--initialize` 参数进行初始化： ```bash mysqld --initialize --basedir=/usr/local/mysql --datadir=/var/lib/mysql ``` 此命令将自动创建系统数据库和表，并为 `root` 用户生成一个临时密码，输出在控制台或错误日志中[^2]。 #### 3. 手动创建系统表（适用于高级用户） 在某些情况下，可能需要手动执行 SQL 脚本来重建系统表。例如，执行以下命令： ```bash mysql -u root < /usr/local/mysql/scripts/mysql_system_tables.sql mysql -u root < /usr/local/mysql/scripts/fill_help_tables.sql ``` 该操作要求 MySQL 服务已启动，并且当前用户具有足够的权限执行 SQL 脚本[^3]。 #### 4. 检查数据目录权限和配置 确保 MySQL 的数据目录路径配置正确，并且 MySQL 用户对该目录具有读写权限。检查 `my.cnf` 或 `my.ini` 文件中配置的 `datadir` 是否指向正确的路径，并确保目录权限设置如下： ```bash chown -R mysql:mysql /var/lib/mysql chmod -R 755 /var/lib/mysql ``` --- ###
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值