MySQL 不能访问启动需要的资源是造成而 MySQL 无法启动的一个常见原因,如:文件,端口等。由于 linux 中用于启动 mysqld 进程的 mysql 用户通常是不能登陆的,可以使用类似下面的命令检查文件的访问权限。
找出问题后,修改对应文件或目录的权限或属主后通常可以解决问题。但有时 mysql 用户有访问文件和目录的权限,但仍然会被拒绝访问,例如下面这个例子:
测试说明 mysql 用户有这个目录的访问权限,但创建文件还是失败,这种情况让很多人困惑,这个时候通常是 mysqld 进程的访问被 linux 的 selinux 或 apparmor 给阻止了,大家可以看到创建的表不是在 mysql 的默认目录下面,因此 selinux 或 apparmor 的 policy 里面没有包含这个目录的访问权限,此时只要对应的修改 policy 就行了,当然把 selinux 或 apparmor 停了也行。
有时虽然对系统资源有访问的权限,但系统资源已经被占用:
这个故障产生的原因是另外一个 mysqld 进程已经启动并占用了对应的文件。
参数设置错误造成 MySQL 无法启动的原因也非常常见,此时先要检查 MySQL 启动时会调用的参数,下面的命令可以查询 MySQL 启动时调用参数文件的顺序:
知道了 MySQL 参数文件的调用顺序,我们就可以检查对应的参数文件,找出其中的错误,如果觉得参数文件的可读性不强,可以使用下面的命令显示 mysqld 程序将要调用的参数:
注意这个命令显示完参数后就退出,不会真正运行 mysqld。这个命令和 my_print_defaults mysqld 完全是等价的,只不过后者的显示方式是一行一个参数。
然后开始对可疑的参数进行调试,我个人喜欢加的参数和顺序如下:
看这个例子:
看这个例子,我们很容易知道是需要我们同时设置参数 GTID_MODE 和 ENFORCE_GTID_CONSISTENCY 同时为 on 才行。
现象:mysql安装后通过 service mysqld start 无法启动。
报错信息如下:
主要含义是说:
mysql启动过程中找不到 /var/lib/mysql/aria_log_control 这个文件;
或者这个文件存在但是打不开。
所以我怀疑的方向有两个:
1、 /var/lib/mysql/aria_log_control 这个文件不存在;
切换到/var/lib/mysql目录下,查看文件是否存在:
可以看到文件是存在的,只是这个文件的属主不对,这里是root,应该是mysql用户和用户组才对。
2、所以应该是第二个怀疑的方向,文件存在,但是没有权限 *** 作:
把该文件的属主改为mysql:
chown -R mysql.mysql /var/lib/mysql
并修改文件的 *** 作权限:
chmod 755 /var/lib/mysql
再执行 service mysqld start 就可以正常启动了。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)