您的位置:

mysql数据库不能启动(mysql 不能启动)

本文目录一览:

mysql 数据库无法启动

故障处理

移除当前使用的 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,采用排除法逐步找出错误的参数。

mysql无法启动

故障处理

移除当前使用的 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 服务无法启动

这个问题出现在MySQL5.7之后的版本,主要的原因是MySQL会在最新的check point完成后都会在redolog写一个一字节的MLOG_CHECKPOINT标记,用来标记在此之前的redo都已checkpoint完成。

如果处于任何原因没有找到这个标记,那么整个redolog文件都会被忽略。出现这个错误的话,最好是有备份进行恢复,如果没有做好备份,那只能采取非常规的启动方式,但可能造成数据丢失。

介绍

MySQL是一个关系型数据库管理系统,由瑞典MySQLAB公司开发,属于Oracle旗下产品。MySQL是最流行的关系型数据库管理系统之一,在WEB应用方面,MySQL是最好的RDBMS应用软件之一。

MySQL是一种关系型数据库管理系统,关系数据库将数据保存在不同的表中,而不是将所有数据放在一个大仓库内,这样就增加了速度并提高了灵活性。