线上数据库服务器上mysql运行一段时间了，突然出现了异常：
启动mysql后随即就又关闭了，mysql服务启动失败！！
查看mysql错误日志如下：
16092022:41:41 mysqld_safe Starting mysqld daemon with databases from /home/MysqlData/ 2021-09-2022:41:41 0 [Note] /Data/app/mysql5.6.25/bin/mysqld (mysqld 5.6.25-log) starting as process 32372 ... 2021-09-2022:41:42 32372 [Note] Plugin 'FEDERATED' is disabled. 2021-09-2022:41:42 32372 [Warning] option 'innodb-write-io-threads': unsigned value 1000 adjusted to 642021-09-2022:41:42 32372 [Warning] option 'innodb-read-io-threads': unsigned value 1000 adjusted to 642021-09-2022:41:42 32372 [Note] InnoDB: Using atomics to ref count buffer pool pages 2021-09-2022:41:42 32372 [Note] InnoDB: The InnoDB memory heap is disabled 2021-09-2022:41:42 32372 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2021-09-2022:41:42 32372 [Note] InnoDB: Memory barrier is not used 2021-09-2022:41:42 32372 [Note] InnoDB: Compressed tables use zlib 1.2.3 2021-09-2022:41:42 32372 [Note] InnoDB: Using CPU crc32 instructions 2021-09-2022:41:42 32372 [Note] InnoDB: Initializing buffer pool, size =1.0G 2021-09-2022:41:42 32372 [Note] InnoDB: Completed initialization of buffer pool 2021-09-2022:41:42 32372 [Note] InnoDB: Highest supported file format is Barracuda. 2021-09-2022:41:42 32372 [Note] InnoDB: Log scan progressed past the checkpoint lsn 202935879572021-09-2022:41:42 32372 [Note] InnoDB: Database was not shutdown normally! 2021-09-2022:41:42 32372 [Note] InnoDB: Starting crash recovery. 2021-09-2022:41:42 32372 [Note] InnoDB: Reading tablespace information from the .ibd files... 2021-09-2022:41:42 32372 [Note] InnoDB: Restoring possible half-written data pages 2021-09-2022:41:42 32372 [Note] InnoDB: from the doublewrite buffer... InnoDB: Doing recovery: scanned up to log sequence number 202935961302021-09-2022:41:42 32372 [Note] InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899InnoDB: Apply batch completed InnoDB: Last MySQL binlog file position 0136254, file name mysql-bin.000013 2021-09-2022:41:43 32372 [Note] InnoDB: 128 rollback segment(s) are active. 2021-09-2022:41:43 32372 [Note] InnoDB: Waiting for purge to start2021-09-2022:41:43 7f77a9edd700 InnoDB: Assertion failure in thread 140151928772352in file trx0purge.cc line 699InnoDB: Failing assertion: purge_sys->iter.trx_no <= purge_sys->rseg->last_trx_no 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. 02:41:43 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.
分析日志后发现，数据库无法重启的原因是因为ibdata1文件 (即共享表空间) 损坏，重启后无法正常恢复。
解决办法：
需要跳过恢复步骤，修改my.cnf文件，在my.cnf中的[mysqld]中添加：
innodb_force_recovery = 6
innodb_purge_threads = 1
修改后，接着重启Mysql服务，发现可正常启动。如果还是无法启动，则就需要删除mysql数据目录下的 "ibdata1、ib_logfile*" 等文件 (删除前，提前做好备份)，然后再做Mysql服务启动操作！！
########innodb_force_recovery参数说明 ################
MySQL数据库当innodb表空间损坏时（如ibdata1文件损坏），尝试启动Mysql服务失败。这个时候可以使用innodb_force_recovery参数进行强制启动！！下面说下这个参数的用法：
innodb_force_recovery参数解释： ------------------------------------------------------------------------------------------------------------- innodb_force_recovery影响整个InnoDB存储引擎的恢复状况，默认值为0，表示当需要恢复时执行所有的恢复操作！！ 当不能进行有效的恢复操作时，Mysql有可能无法启动，并记录下错误日志。 innodb_force_recovery可以设置为1-6，大的数字包含前面所有数字的影响。 当该参数的数值设置大于0后，可以对表进行select，create，drop操作，但insert，update或者delete这类操作是不允许的。 innodb_force_recovery=0 表示当需要恢复时执行所有的恢复操作； innodb_force_recovery=1 表示忽略检查到的corrupt页； innodb_force_recovery=2 表示阻止主线程的运行，如主线程需要执行full purge操作，会导致crash； innodb_force_recovery=3 表示不执行事务回滚操作； innodb_force_recovery=4 表示不执行插入缓冲的合并操作； innodb_force_recovery=5 表示不查看重做日志，InnoDB存储引擎会将未提交的事务视为已提交； innodb_force_recovery=6 表示不执行前滚的操作，强制重启！ ------------------------------------------------------------------------------------------------------------- 记一次事故： 线上Mysql环境采用一主两从模式，突然一天上午发现主从库的Mysql服务都启动失败，最后排查是Mysql共享表空间ibdata1文件损坏了。 恢复记录： 1) 在主从库的Mysql配置文件my.cnf中添加 # vim /etc/my.cnf innodb_force_recovery=6 2) 启动mysql服务 # service mysqld start 3）如果启动成功后，再将my.cnf文件中的"innodb_force_recovery=6"配置去掉，然后再次尝试mysql服务的重启，应该OK。 在主从库出现这种情况时，如果配置文件里之前就有这个参数，则尝试将该参数值修改为0或6，依次尝试重启。 ———————————————— 版权声明：本文为CSDN博主「林中静月下仙」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/qq_21137441/article/details/122949036
*************** 当你发现自己的才华撑不起野心时，就请安静下来学习吧！***************
