怎么解决mysql服务无法启动的问题

Posted 2023-03-24

1、情况一：mysql的错误日志文件（安装目录\MYOA\data5\机器名.err）会记录如下内容：
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Error: trying to add tablespace 460 of name '.\td_oa\flow_data_35.ibd'
InnoDB: to the tablespace memory cache, but tablespace
InnoDB: 460 of name '.\td_oa\exam_data.ibd' already exists in the tablespace
解决方法：
1）剪切出安装目录\MYOA\data5\TD_OA的flow_data_35.ibd和flow_data_35.frm两个文件；
2）启动MySQL5_OA服务，使用备份的flow_data_35.sql导入到TD_OA库中。如果提示flow_data_35表已经存在不能导入，则继续按后续步骤执行；
3）在data5下手动建立tmp目录；
4）使用MySQL管理工具或MySQL命令行程序在tmp下建立名称为flow_data_35的表（包含一个字段即可）；
5）将tmp下的flow_data_35.frm和flow_data_35.ibd拷贝到安装目录\MYOA\data5\TD_OA目录下；
6）在MySQL管理工具或MySQL命令行程序中，进入TD_OA库，使用“drop table flow_data_35;”命令清除公共表空间中残留的flow_data_35表的相关信息；
7）进入tmp库，删掉flow_data_35表；
8）使用备份的flow_data_35.sql导入到TD_OA库中；
9）如果还有其他表存在该问题，可重复执行4至8步骤。
2、情况二：MySQL的错误日志文件（安装目录\MYOA\data5\机器名.err）会记录如下内容：
130409 15:54:31 [Note] Plugin 'FEDERATED' is disabled.
130409 15:54:31 InnoDB: The InnoDB memory heap is disabled
130409 15:54:31 InnoDB: Mutexes and rw_locks use Windows interlocked functions
130409 15:54:31 InnoDB: Compressed tables use zlib 1.2.3
130409 15:54:32 InnoDB: Initializing buffer pool, size = 1023.0M
InnoDB: VirtualAlloc(1086849024 bytes) failed; Windows error 8
130409 15:54:32 InnoDB: Completed initialization of buffer pool
130409 15:54:32 InnoDB: Fatal error: cannot allocate memory for the buffer pool
130409 15:54:32 [ERROR] Plugin 'InnoDB' init function returned error.
130409 15:54:32 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
130409 15:54:32 [ERROR] Unknown/unsupported storage engine: Innodb
130409 15:54:32 [ERROR] Aborting
解决方法：
此情况出现的原因是myoa\mysql5\my.ini中innodb_buffer_pool_size的值太大，OA服务器操作系统不支持所致。改小后再启动mysql5_OA服务即可，一般保持和数据库大小一致。数据库大小即是myoa/data5的大小。
3、情况三：mysql服务启动不了，事件查看器中显示：The syntax '--log-slow-queries' is deprecated and will be removed in a future release. Please use '--slow-query-log'/'--slow-query-log-file' instead.
解决方法：安装目录\MYOA\data5下的ibdata1、ib_logfile0、ib_logfile1文件属性被设置为只读导致，取消只读控制，重启mysql5_OA服务即可。
4、情况四：MySQL的错误日志文件（data5\机器名.err）会记录如下内容：InnoDB: No valid checkpoint found.
解决方法：此问题找不到检查点，数据库是无效的，此种情况，只能用热备份数据恢复。
5、以上四种情况，是2013版OA系统目前比较常见的mysql服务启动不了的现象和解决办法，大家可作参考，其他情况的话，再具体分析处理。
6、分析思路总结：遇到mysql5_OA服务启动不了的情况，首先查看myoa\data5下的错误日志文件，根据日志中的具体内容进行具体分析。
7、2013版MYSQL服务启动不了（可以尝试强制启动mysql服务）方法如下：
1)打开\MYOA\mysql5\my.ini，去掉innodb_force_recovery=1前边的注释。
2)启动MySQL5_OA服务，此时MySQL处于只读状态，可以导出，不可写入。如果仍不能启动，可以尝试将innodb_force_recovery修改为2、3、4、5、6等，直到可以启动为止。
3)使用MySQL管理工具，将TD_OA等相关的数据库导出为SQL文件。
4)停止MySQL5_OA服务，删除TD_OA下的所有文件、ibdata1、ib_logfile0、ib_logfile1等文件。
5）打开\MYOA\mysql5\my.ini，在innodb_force_recovery=1前边加上#号，将该项注释掉。
6)启动MySQL5_OA服务，然后导入此前备份的SQL文件。
7)检查数据库，将无法通过该方法恢复的数据表，通过之前自动备份的SQL文件进行恢复。 参考技术A 故障处理
移除当前使用的 redo log 文件，然后可以试着启动数据库，结果启动失败！
提示：
[ERROR] InnoDB: Page [page id: space=0, page number=0] log sequence number 178377412422 is in the future! Current system log sequence number 165909011496.
这样的错误，这是因为 MySQL writer 线程按照配置的时间间隔以 page 为单位刷新 buffer 数据到磁盘。当数据刷新到磁盘的时候，新写入磁盘的 page 包含了较新的 LSN，此时系统 system 表空间头的 LSN 并没有同步更新，通常这是检查点线程的工作。在正常的崩溃恢复中，MySQL 可以借助 redo log 来进行前滚和回滚，但是此时 redo log 已经被我们删掉了，MySQL 无法进行恢复操作。此时，我们设置 innodb_force_recovery=3 来强制启动 MySQL，仍然启动不成功，改成 4 后启动了！
再使用 mysqldump 导出备份，结果噩梦又降临了！MySQL 又 crash 了。
提示：
InnDB: Failed to find tablespace for table......
设置参数 innodb_force_recovery=5，数据库仍然启动失败，再设置成 6，启动成功！用 sqldump 顺利把数据备份出来了！
再初始化数据库，把刚刚备份的数据库导入，数据库恢复成功完成！

参数说明
这里的关键是设置 innodb_force_recovery 参数，对应这个参数的说明如下：
1. SRV_FORCE_IGNORE_CORRUPT：忽略检查到的 corrupt 页；
2. SRV_FORCE_NO_BACKGROUND：阻止主线程的运行，如主线程需要执行 full purge 操作，会导致 crash；
3. SRV_FORCE_NO_TRX_UNDO：不执行事务回滚操作；
4. SRV_FORCE_NO_IBUF_MERGE：不执行插入缓冲的合并操作；
5. SRV_FORCE_NO_UNDO_LOG_SCAN：不查看重做日志，InnoDB 存储引擎会将未提交的事务视为已提交；
6. SRV_FORCE_NO_LOG_REDO：不执行前滚的操作。

mysql启动不了服务启动不了该怎么办

一、无法访问系统资源
MySQL 不能访问启动需要的资源是造成而 MySQL 无法启动的一个常见原因，如：文件，端口等。由于 linux 中用于启动 mysqld 进程的 mysql 用户通常是不能登陆的，可以使用类似下面的命令检查文件的访问权限。
sudo -u mysql touch /var/lib/mysql/b

找出问题后，修改对应文件或目录的权限或属主后通常可以解决问题。但有时 mysql 用户有访问文件和目录的权限，但仍然会被拒绝访问，例如下面这个例子：
mysql> system sudo -u mysql touch /home/mysql/data/a
mysql> create table t1 (
id int primary key,n varchar(10
) data directory
ERROR 1030 (HY000): Got error 168 from storage engine

测试说明 mysql 用户有这个目录的访问权限，但创建文件还是失败，这种情况让很多人困惑，这个时候通常是 mysqld 进程的访问被 linux 的 selinux 或 apparmor 给阻止了，大家可以看到创建的表不是在 mysql 的默认目录下面，因此 selinux 或 apparmor 的 policy 里面没有包含这个目录的访问权限，此时只要对应的修改 policy 就行了，当然把 selinux 或 apparmor 停了也行。
有时虽然对系统资源有访问的权限，但系统资源已经被占用：
mysqld --no-defaults --console --user mysql
2020-11-03T03:36:07.519419Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.19) starting as process 21171
2020-11-03T03:36:07.740347Z 1 [ERROR] [MY-012574] [InnoDB] Unable to lock ./ibdata1 error: 11

这个故障产生的原因是另外一个 mysqld 进程已经启动并占用了对应的文件。

二、参数设置错误
参数设置错误造成 MySQL 无法启动的原因也非常常见，此时先要检查 MySQL 启动时会调用的参数，下面的命令可以查询 MySQL 启动时调用参数文件的顺序：
$ mysqld --verbose --help | grep "Default options " -A 1
Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf

知道了 MySQL 参数文件的调用顺序，我们就可以检查对应的参数文件，找出其中的错误，如果觉得参数文件的可读性不强，可以使用下面的命令显示 mysqld 程序将要调用的参数：
$ mysqld --print-defaults
/usr/sbin/mysqld would have been started with the following arguments:
......

注意这个命令显示完参数后就退出，不会真正运行 mysqld。这个命令和 my_print_defaults mysqld 完全是等价的，只不过后者的显示方式是一行一个参数。
然后开始对可疑的参数进行调试，我个人喜欢加的参数和顺序如下：
1. 在 mysqld 后加上第一个参数 --no-defaults ，这个参数的作用是通知 mysqld 在启动的时候不要读任何参数文件；
2. 第二个参数是 --console，这个参数会把错误信息输出到屏幕上，这个参数带来的一个弊端是所有的信息都输出到屏幕上，让屏幕显得比较乱，但对于我们调试却是很方便的；
3. 第三个参数是 --log-error-verbosity=3，这个参数会显示详细的日志；
4. 然后再在后面加上有把握的参数，可以一次只加一个参数，然后启动 mysqld，采用排除法逐步找出错误的参数。 参考技术A 找到mysql安装目录，将其配置文件my.default.ini改名为my.ini，并且将my.ini移至bin目录下。

启动命令行，将目录切换到mysql安装目录的bin目录下。

接下来，在命令行执行命令：mysqld --initialize --user=mysql --console

注意，上一个步骤会获得一个临时密码，需要记录，之后会用到。

接下来在控制台以命令行输入： mysqld --install，进行安装服务操作。

之后，在任务管理器找到“服务”，启动其中的MYSQL服务即可。

之后，输入命令行mysql -uroot -p，利用之前的临时密码输入即可登录数据库成功。

修改临时密码，设置密码：mysqladmin -u USER -p password PASSWORD，注意USER和PASSWORD为自己定义的数值。本回答被提问者采纳