Mysql 无法启动 - ibdata1 损坏? - 操作系统错误号 13 - 权限问题

发布于 2024-09-26 23:21:24 字数 608 浏览 4 评论 0原文

服务器因电源故障而关闭。
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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(14

妖妓 2024-10-03 23:21:24

如果您使用的是 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 new DATADIR.

It should work.

陈年往事 2024-10-03 23:21:24

错误:

101130 14:42:51 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
101130 18:07:58 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
101130 18:07:58  InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name ./ibdata1
InnoDB: File operation call: 'open'.
InnoDB: Cannot continue operation.

SeLinux 解决方案 SeLinux 安全性:

[root@localhost ~]# service mysqld restart
Deteniendo mysqld:                                         [  OK  ]
Iniciando mysqld:                                          [  FALLÓ  ]
[root@localhost ~]#  restorecon -R /var/lib/mysql/
[root@localhost ~]# service mysqld restart
Deteniendo mysqld:                                         [  OK  ]
Iniciando mysqld:                                          [  OK  ]
[root@localhost ~]#

Error:

101130 14:42:51 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
101130 18:07:58 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
101130 18:07:58  InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name ./ibdata1
InnoDB: File operation call: 'open'.
InnoDB: Cannot continue operation.

Solution SeLinux SeLinux security:

[root@localhost ~]# service mysqld restart
Deteniendo mysqld:                                         [  OK  ]
Iniciando mysqld:                                          [  FALLÓ  ]
[root@localhost ~]#  restorecon -R /var/lib/mysql/
[root@localhost ~]# service mysqld restart
Deteniendo mysqld:                                         [  OK  ]
Iniciando mysqld:                                          [  OK  ]
[root@localhost ~]#
孤芳又自赏 2024-10-03 23:21:24

请检查这个:

chown -R mysql:mysql /var/lib/mysql

please check this:

chown -R mysql:mysql /var/lib/mysql
墨洒年华 2024-10-03 23:21:24

该文件没有损坏。您可以使用“perror”找出这些错误的来源。即

toaster:~ morgo$ perror 13
OS error code  13:  Permission denied

InnoDB 有损坏检测(页面校验和),并且会很高兴地告诉您这是否是问题所在。

目录权限已更改,或者您的 my.cnf 文件已被删除,并且它正在尝试在其他地方重新创建数据文件。

The file is not corrupt. You can find out the source of these errors with 'perror'. i.e.

toaster:~ morgo$ perror 13
OS error code  13:  Permission denied

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.

维持三分热 2024-10-03 23:21:24

对我来说,恢复安全上下文(selinux)就可以了

restorecon -R /var/lib/mysql/

For me, restoring the security context (selinux) did the trick

restorecon -R /var/lib/mysql/

梦萦几度 2024-10-03 23:21:24

简而言之,(尤其是在 RHEL/CentOS/Fedora 上)尝试一下

getenforce

它是否回复 Enforcing 您已启动并运行 SELinux。使用 setenforce 0 暂时停用它,看看 MariaDB 现在是否启动!相当常见,尤其是在 RHEL/CentOS/Fedora 上。

下面还有更多相关内容,以及 这篇官方文章

一般来说,

在 UNIX 环境中,除了用户访问权限之外,还有更多因素可能会阻止文件访问。

  • 像 SELinux(见上文)或 AppArmor(如 Dan 提到的)这样的安全模块可能会禁止它
  • 可以针对所需的文件/目录专门设置访问控制列表 (ACL)
  • 任何父文件夹都可以由另一个用户拥有,并且没有权限为其他人设置的 x (="dir access")

此外,可能还有其他意外因素,例如...

  • mysql datadir 被设置到 mysql 没有权限的位置(请参阅>/etc/my.cnf
  • Mysql 可能(奇怪地)以不同的用户身份运行,或者该文件可能只是由其他人拥有

只是提一下我的想法(随意顺便说一句,编辑/添加到这个答案)。

在这种情况下,SELinux 是“问题”

对于永久解决方案,您可以尝试恢复适当的安全上下文,……

restorecon -R /var/lib/mysql/

或者只是停用 SELinux(但在这样做之前稍微考虑一下这一点),通过编辑配置(通常在 /etc/selinux/config 中)并按照以下文章中的建议设置 SELINUX=disabled

显然这些同样适用于MySQL。

In short, (especially on RHEL/CentOS/Fedora) try

getenforce

if it replies with Enforcing you have SELinux up and running. Temporarily deactivate it with setenforce 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.

  • Security modules like SELinux (see above) or AppArmor (as Dan mentioned) could disallow it
  • Access Control Lists (ACL) could be specifically set, for the required files/directories
  • Any of the parent folders could be owned by another user, and have no x (="dir access") set for others

Additionally there could be other unexpected factors, like ...

  • The mysql datadir being set to a place, where mysql doesn't have permissions (see /etc/my.cnf)
  • Mysql could (strangely) be running as a different user, or the file could be simply owned by someone else

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, ...

restorecon -R /var/lib/mysql/

... 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 setting SELINUX=disabled as suggested in following article.

Obviously those are applicable to MySQL just the same way.

萌辣 2024-10-03 23:21:24

我的 CentOS 机器上也遇到了完全相同的问题。移动 mysql 数据目录后,即使我复制了具有相同所有者和权限的文件,我也无法再启动该服务。

我在 SELinux 安全上下文方面遇到了问题。如果您运行 CentOS 库存,它很有可能被启用,并且不会让 MySQL 执行您想要的操作。要解决此问题:

首先使用 和 比较旧目录和新目录

ls -Z /var/lib/mysql 

ls -Z /new/mysql/dir

如果您发现任何差异,则可能是您的问题。
要修改它:

chcon -R --type=mysql_db_t /new/mysql/dir

-R 开关用于递归。如果您只需要更改一个文件,则可以忽略它。
如果您的上下文与我的不同(可能是不同的发行版),请使用第一个输出指示的上下文(它应该是 SELinux 内容的第三个字段)

ls -Z /var/lib/mysql 

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

ls -Z /var/lib/mysql 

and

ls -Z /new/mysql/dir

If you see any difference it's likely to be your problem.
To modify this :

chcon -R --type=mysql_db_t /new/mysql/dir

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)

ls -Z /var/lib/mysql 
何其悲哀 2024-10-03 23:21:24

我遇到了同样的问题,并通过以下步骤修复

工作目录 /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

难得心□动 2024-10-03 23:21:24

我的 CentOS 机器上也遇到了完全相同的问题。移动 mysql 数据目录后,即使我复制了具有相同所有者和权限的文件,我也无法再启动该服务。

我在 SELinux 安全上下文方面遇到了问题。如果您运行 CentOS 库存,它很有可能被启用,并且不会让 MySQL 执行您想要的操作。要解决此问题:

首先使用 和 比较旧目录和新目录

ls -Z /var/lib/mysql 

ls -Z /new/mysql/dir

如果您发现任何差异,则可能是您的问题。
要修改它:

chcon -R --type=mysql_db_t /new/mysql/dir

-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

ls -Z /var/lib/mysql 

and

ls -Z /new/mysql/dir

If you see any difference it's likely to be your problem.
To modify this :

chcon -R --type=mysql_db_t /new/mysql/dir

The -R switch is for recursion. If you only need to change one file you can omit it.

丶视觉 2024-10-03 23:21:24

当这个问题出现时,我在 /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. The datadir 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.

唐婉 2024-10-03 23:21:24

如果您使用 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 有什么不同的安全上下文。

semanage fcontext -l | grep mysqld
/etc/mysql(/.*)?                       all files    system_u:object_r:mysqld_etc_t:s0
/etc/my\.cnf\.d(/.*)?                  all files    system_u:object_r:mysqld_etc_t:s0
/var/log/mysql.*                       regular file system_u:object_r:mysqld_log_t:s0
/var/lib/mysql(-files|-keyring)?(/.*)? all files    system_u:object_r:mysqld_db_t:s0
/var/run/mysqld(/.*)?                  all files    system_u:object_r:mysqld_var_run_t:s0
/var/log/mariadb(/.*)?                 all file     system_u:object_r:mysqld_log_t:s0
/var/run/mariadb(/.*)?                 all files    system_u:object_r:mysqld_var_run_t:s0
/usr/sbin/mysqld(-max)?                regular file system_u:object_r:mysqld_exec_t:s0
/var/run/mysqld/mysqlmanager.*         regular file system_u:object_r:mysqlmanagerd_var_run_t:s0
/usr/lib/systemd/system/mysqld.*       regular file system_u:object_r:mysqld_unit_file_t:s0
/usr/lib/systemd/system/mariadb.*      regular file system_u:object_r:mysqld_unit_file_t:s0
/etc/my\.cnf                           regular file system_u:object_r:mysqld_etc_t:s0
/root/\.my\.cnf                        regular file system_u:object_r:mysqld_home_t:s0
/usr/sbin/ndbd                         regular file system_u:object_r:mysqld_exec_t:s0
/usr/libexec/mysqld                    regular file system_u:object_r:mysqld_exec_t:s0
/usr/bin/mysqld_safe                   regular file system_u:object_r:mysqld_safe_exec_t:s0
/usr/bin/mysql_upgrade                 regular file system_u:object_r:mysqld_exec_t:s0
/etc/rc\.d/init\.d/mysqld              regular file system_u:object_r:mysqld_initrc_exec_t:s0
/var/lib/mysql/mysql\.sock             socket       system_u:object_r:mysqld_var_run_t:s0
/usr/libexec/mysqld_safe-scl-helper    regular file system_u:object_r:mysqld_safe_exec_t:s0
/home/[^/]+/\.my\.cnf                  regular file unconfined_u:object_r:mysqld_home_t:s0

在这里您可以看到 mysqld 的所有上下文,其中包含解释的简短列表

  1. mysqld_etc_t - 配置文件
  2. mysqld_db_t - 数据数据库文件
  3. mysqld_log_t - 日志文件
  4. mysqld_exec_t - 执行文件

因此,如果您的文件上有错误的安全上下文,您会收到权限被拒绝(错误 13)的

解决方案

chcon -R -u system_u -t mysqld_db_t  /var/lib/mysql

但也要检查“正常”权限。我在使用 centos 时遇到了这个问题。您必须 systemctl restart mysql 才能进行更改。

If you use SEL Linux

Intall semanage

yum whatprovides /usr/sbin/semanage you get policycoreutils-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.

semanage fcontext -l | grep mysqld
/etc/mysql(/.*)?                       all files    system_u:object_r:mysqld_etc_t:s0
/etc/my\.cnf\.d(/.*)?                  all files    system_u:object_r:mysqld_etc_t:s0
/var/log/mysql.*                       regular file system_u:object_r:mysqld_log_t:s0
/var/lib/mysql(-files|-keyring)?(/.*)? all files    system_u:object_r:mysqld_db_t:s0
/var/run/mysqld(/.*)?                  all files    system_u:object_r:mysqld_var_run_t:s0
/var/log/mariadb(/.*)?                 all file     system_u:object_r:mysqld_log_t:s0
/var/run/mariadb(/.*)?                 all files    system_u:object_r:mysqld_var_run_t:s0
/usr/sbin/mysqld(-max)?                regular file system_u:object_r:mysqld_exec_t:s0
/var/run/mysqld/mysqlmanager.*         regular file system_u:object_r:mysqlmanagerd_var_run_t:s0
/usr/lib/systemd/system/mysqld.*       regular file system_u:object_r:mysqld_unit_file_t:s0
/usr/lib/systemd/system/mariadb.*      regular file system_u:object_r:mysqld_unit_file_t:s0
/etc/my\.cnf                           regular file system_u:object_r:mysqld_etc_t:s0
/root/\.my\.cnf                        regular file system_u:object_r:mysqld_home_t:s0
/usr/sbin/ndbd                         regular file system_u:object_r:mysqld_exec_t:s0
/usr/libexec/mysqld                    regular file system_u:object_r:mysqld_exec_t:s0
/usr/bin/mysqld_safe                   regular file system_u:object_r:mysqld_safe_exec_t:s0
/usr/bin/mysql_upgrade                 regular file system_u:object_r:mysqld_exec_t:s0
/etc/rc\.d/init\.d/mysqld              regular file system_u:object_r:mysqld_initrc_exec_t:s0
/var/lib/mysql/mysql\.sock             socket       system_u:object_r:mysqld_var_run_t:s0
/usr/libexec/mysqld_safe-scl-helper    regular file system_u:object_r:mysqld_safe_exec_t:s0
/home/[^/]+/\.my\.cnf                  regular file unconfined_u:object_r:mysqld_home_t:s0

Here you see all context for mysqld a short list with explanation

  1. mysqld_etc_t - config files
  2. mysqld_db_t - data db files
  3. mysqld_log_t - log files
  4. mysqld_exec_t - execution files

So if you have the wrong security context on your files you get a permission denied (error 13)

Solution

chcon -R -u system_u -t mysqld_db_t  /var/lib/mysql

But check the "normal" permissions, too. I had this problem with centos. You have to systemctl restart mysql for the changes.

椒妓 2024-10-03 23:21:24

在我看来是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.

孤芳又自赏 2024-10-03 23:21:24

如果您在 Synology NAS 上遇到此问题,您可以按照 Synology 支持团队的建议修复该问题:

尊敬的用户,

这已被确认为已知问题,我们将尝试在进一步的 MariaDB 版本中修复此问题。很抱歉给您带来不便。

解决方法如下:

  • 请尝试使用“root”帐户和密码(与管理员的密码相同)远程登录到您的 DS
  • 运行命令“echo 1 > /var/services/mysql/VERSION”
  • 从 DSM 打开 MariaDB 软件包将再次触发更新
  • 输入数据库密码并单击“更新”即可修复此问题

更多信息:群晖论坛

If you have this problem on a Synology NAS you can fix it by following the advice of the Synology support team:

Dear User,

This has been confirmed as a known issue and we will try to fix this issue in further MariaDB release. Sorry for your inconvenience.

Here is the workaround:

  • Please try to telnet to your DS with "root" account and password (same as admin's)
  • run the command "echo 1 > /var/services/mysql/VERSION"
  • open MariaDB package from DSM will trigger update again
  • type in the DB password and click Update will fix this issue

More info: Synology forum

书信已泛黄 2024-10-03 23:21:24

我也有同样的问题。
做了很多研究并找到了这个解决方案。
您需要在 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文