Mysql 无法启动 - ibdata1 损坏? - 操作系统错误号 13 - 权限问题
服务器因电源故障而关闭。
Mysql 现在无法启动。
磁盘未满。 系统日志如下
Oct 11 15:03:31 joe mysqld_safe[24757]: started
Oct 11 15:03:31 joe mysqld[24760]: 101011 15:03:31 InnoDB: Operating system error number 13 in a file operation.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: The error means mysqld does not have the access rights to
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: the directory.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: File name ./ibdata1
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: File operation call: 'create'.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: Cannot continue operation.
Server shutdown from power failure.
Mysql will not start now.
Disk is not full.
Syslog is below
Oct 11 15:03:31 joe mysqld_safe[24757]: started
Oct 11 15:03:31 joe mysqld[24760]: 101011 15:03:31 InnoDB: Operating system error number 13 in a file operation.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: The error means mysqld does not have the access rights to
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: the directory.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: File name ./ibdata1
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: File operation call: 'create'.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: Cannot continue operation.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(14)
如果您使用的是 ubuntu 或 apparmor,您应该允许 apparmor 中的此更改。
编辑
/etc/apparmor.d/usr.sbin.mysqld
并使用新的DATADIR
更改/var/lib/mysql
。它应该有效。
If you are using ubuntu or apparmor you should permit this change in apparmor.
Edit
/etc/apparmor.d/usr.sbin.mysqld
and change/var/lib/mysql
with the newDATADIR
.It should work.
错误:
SeLinux 解决方案 SeLinux 安全性:
Error:
Solution SeLinux SeLinux security:
请检查这个:
please check this:
该文件没有损坏。您可以使用“perror”找出这些错误的来源。即
InnoDB 有损坏检测(页面校验和),并且会很高兴地告诉您这是否是问题所在。
目录权限已更改,或者您的 my.cnf 文件已被删除,并且它正在尝试在其他地方重新创建数据文件。
The file is not corrupt. You can find out the source of these errors with 'perror'. i.e.
InnoDB has corruption detection (page checksums) and would happily tell you if that were the problem.
Either the directory permissions have changed, or your my.cnf file has been hosed, and it's trying to recreate data files somewhere else.
对我来说,恢复安全上下文(selinux)就可以了
restorecon -R /var/lib/mysql/
For me, restoring the security context (selinux) did the trick
restorecon -R /var/lib/mysql/
简而言之,(尤其是在 RHEL/CentOS/Fedora 上)尝试一下
它是否回复
Enforcing
您已启动并运行 SELinux。使用setenforce 0
暂时停用它,看看 MariaDB 现在是否启动!相当常见,尤其是在 RHEL/CentOS/Fedora 上。下面还有更多相关内容,以及 这篇官方文章。
一般来说,
在 UNIX 环境中,除了用户访问权限之外,还有更多因素可能会阻止文件访问。
此外,可能还有其他意外因素,例如...
datadir
被设置到 mysql 没有权限的位置(请参阅>/etc/my.cnf
)只是提一下我的想法(随意顺便说一句,编辑/添加到这个答案)。
在这种情况下,SELinux 是“问题”
对于永久解决方案,您可以尝试恢复适当的安全上下文,……
或者只是停用 SELinux(但在这样做之前稍微考虑一下这一点),通过编辑配置(通常在
/etc/selinux/config
中)并按照以下文章中的建议设置SELINUX=disabled
。显然这些同样适用于MySQL。
In short, (especially on RHEL/CentOS/Fedora) try
if it replies with
Enforcing
you have SELinux up and running. Temporarily deactivate it withsetenforce 0
and see if MariaDB starts now! Rather common, especially on RHEL/CentOS/Fedora.There's more about this further down, as well as in this official article.
In general
There are more things in a UNIX environment that might prevent file access, than just user access rights.
Additionally there could be other unexpected factors, like ...
datadir
being set to a place, where mysql doesn't have permissions (see/etc/my.cnf
)Just to mention a view things off the top of my head (feel free to edit/add to this answer btw).
In the case, SELinux is "the problem"
For a permanent solution, you could try to restore the appropriate security context, ...
... or just deactivate SELinux (but think about this one a little bit before doing so), by editing the config (typically in
/etc/selinux/config
) and settingSELINUX=disabled
as suggested in following article.Obviously those are applicable to MySQL just the same way.
我的 CentOS 机器上也遇到了完全相同的问题。移动 mysql 数据目录后,即使我复制了具有相同所有者和权限的文件,我也无法再启动该服务。
我在 SELinux 安全上下文方面遇到了问题。如果您运行 CentOS 库存,它很有可能被启用,并且不会让 MySQL 执行您想要的操作。要解决此问题:
首先使用 和 比较旧目录和新目录
,
如果您发现任何差异,则可能是您的问题。
要修改它:
-R 开关用于递归。如果您只需要更改一个文件,则可以忽略它。
如果您的上下文与我的不同(可能是不同的发行版),请使用第一个输出指示的上下文(它应该是 SELinux 内容的第三个字段)
I had exactly the same problem on my CentOS box. After moving mysql data directory around I couldn't start the service anymore, even as I had copied the files with the same owner and permissions.
I had a problem with the SELinux security context. If you run your CentOS stock it has good chance to be enabled and won't let do what you want with MySQL. To fix this :
First compare the old dir and new dir using
and
If you see any difference it's likely to be your problem.
To modify this :
The -R switch is for recursion. If you only need to change one file you can omit it.
If your context is different than mine(maybe a different distro), use the one indicated by the output of the first (it should be the 3rd field of the SELinux stuff)
我遇到了同样的问题,并通过以下步骤修复
工作目录 /var/lib/mysql
早期 /var/lib/mysql 由某个未知用户拥有
将其更改为 mysql
< code>mysql]# chown -R mysql:mysql *
mysql]# service mariadb start
重定向到 /bin/systemctl start mariadb.service
有效就像魅力一样
I had the same problem and fix by below steps
Working directory /var/lib/mysql
Earlier /var/lib/mysql was owned by some unknown user
Changed it to mysql
mysql]# chown -R mysql:mysql *
mysql]# service mariadb start
Redirecting to /bin/systemctl start mariadb.service
Works like a charm
我的 CentOS 机器上也遇到了完全相同的问题。移动 mysql 数据目录后,即使我复制了具有相同所有者和权限的文件,我也无法再启动该服务。
我在 SELinux 安全上下文方面遇到了问题。如果您运行 CentOS 库存,它很有可能被启用,并且不会让 MySQL 执行您想要的操作。要解决此问题:
首先使用 和 比较旧目录和新目录
,
如果您发现任何差异,则可能是您的问题。
要修改它:
-R 开关用于递归。如果您只需要更改一个文件,则可以忽略它。
I had exactly the same problem on my CentOS box. After moving mysql data directory around I couldn't start the service anymore, even as I had copied the files with the same owner and permissions.
I had a problem with the SELinux security context. If you run your CentOS stock it has good chance to be enabled and won't let do what you want with MySQL. To fix this :
First compare the old dir and new dir using
and
If you see any difference it's likely to be your problem.
To modify this :
The -R switch is for recursion. If you only need to change one file you can omit it.
当这个问题出现时,我在 /etc/mysql/my.cnf 配置文件中找到了答案。
datadir
行没有指向/var/lib/mysql
目录(数据库所在的位置)。一旦我输入此路径,服务器重新启动就没有问题了。When this popped up for me, I found the answer in the
/etc/mysql/my.cnf
configuration file. Thedatadir
line did not point to the/var/lib/mysql
directory (where the databases are). Once I put this path in, the server restarted no problem.如果您使用 SEL Linux
Intall semanage
yum Whatprovides /usr/sbin/semanage
您会得到policycoreutils-python-2.5-22.el7.x86_64
See mysqld security context
After Installation
yum install policycoreutils-python
你可以看看 mysqld 有什么不同的安全上下文。在这里您可以看到 mysqld 的所有上下文,其中包含解释的简短列表
因此,如果您的文件上有错误的安全上下文,您会收到权限被拒绝(错误 13)的
解决方案
但也要检查“正常”权限。我在使用
centos
时遇到了这个问题。您必须systemctl restart mysql
才能进行更改。If you use SEL Linux
Intall semanage
yum whatprovides /usr/sbin/semanage
you getpolicycoreutils-python-2.5-22.el7.x86_64
See mysqld security context
After installation
yum install policycoreutils-python
you can just look what different security context mysqld has.Here you see all context for mysqld a short list with explanation
So if you have the wrong security context on your files you get a permission denied (error 13)
Solution
But check the "normal" permissions, too. I had this problem with
centos
. You have tosystemctl restart mysql
for the changes.在我看来是Selinux的问题。还有
chcon -R --type=mysql_db_t /new/mysql/dir
出现错误:chcon:无法将 /new/mysql/dir 的上下文更改为 root:object_r:mysql_db_t:参数无效
。所以我使用命令:
chcon -R root:object_r:mysqld_db_t /new/mysql/dir
。In my siuation is Selinux's problem. And the
chcon -R --type=mysql_db_t /new/mysql/dir
comes error:chcon: failed to change context of /new/mysql/dir to root:object_r:mysql_db_t: Invalid argument
.So i use the command:
chcon -R root:object_r:mysqld_db_t /new/mysql/dir
.如果您在 Synology NAS 上遇到此问题,您可以按照 Synology 支持团队的建议修复该问题:
更多信息:群晖论坛
If you have this problem on a Synology NAS you can fix it by following the advice of the Synology support team:
More info: Synology forum
我也有同样的问题。
做了很多研究并找到了这个解决方案。
您需要在 ibdata1 上运行此命令
sudo Shadowprotect -u 根 | root
我不知道这是做什么的..但它对我有用。
祝你好运。
I had the same problem.
Did alot of research and found out this solution.
You need to run this command on ibdata1
sudo shadowprotect -u root | root
I dont know what this does.. but it worked for me.
Good luck.