☰

为什么 mariadb 总是死机？我该如何阻止它？

tag-icon • tag-icon 15.10 mysql timeout mariadb
为什么 mariadb 总是死机？我该如何阻止它？

我在 Ubuntu 15.10 上运行 MariaDB 10.0.23-0 作为 LAMP 服务器。运行sudo /etc/init.d/mysql start结果如下：

Job for mariadb.service failed because a timeout was exceeded. See "systemctl status mariadb.service" and "journalctl -xe" for details.

的输出systemctl status mariadb.service为：

● mariadb.service - MariaDB 数据库服务器
   已加载：已加载（/lib/systemd/system/mariadb.service；已启用；供应商预设：已启用）
  插入：/etc/systemd/system/mariadb.service.d
           └─从我的.cnf-settings.conf 迁移
   活动：失败（结果：超时）自 2016-03-26 星期六 22:52:42 EDT；26 秒前
  进程：8707 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER（代码=退出，状态=0/SUCCESS）
  进程：8706 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld（代码=exited，状态=0/SUCCESS）
 主 PID：8707（代码=已退出，状态=0/成功）

3 月 26 日 22:52:39 boggan systemd[1]: mariadb.service: 启动操作超时。正在终止。
3月26日 22:52:39 boggan mysqld[8707]: 2016-03-26 22:52:39 140105856617216 [注意] /usr/sbin/mysqld: 正常关闭
3 月 26 日 22:52:39 boggan mysqld[8707]: 2016-03-26 22:52:39 140105856617216 [注意] 事件调度程序: 清除队列。0 个事件
3 月 26 日 22:52:39 boggan mysqld[8707]: 2016-03-26 22:52:39 140104920164096 [注意] InnoDB: FTS 优化线程退出。
3 月 26 日 22:52:39 boggan mysqld[8707]: 2016-03-26 22:52:39 140105856617216 [注意] InnoDB: 正在开始关闭...
3月26日 22:52:42 boggan mysqld[8707]: 2016-03-26 22:52:42 140105856617216 [注意] InnoDB: 关闭完成；日志序列号 3336953
3月26日 22:52:42 boggan mysqld[8707]: 2016-03-26 22:52:42 140105856617216 [注意] /usr/sbin/mysqld: 关闭完成
3 月 26 日 22:52:42 boggan systemd[1]: 无法启动 MariaDB 数据库服务器。
3 月 26 日 22:52:42 boggan systemd[1]: mariadb.service: 设备进入故障状态。
3 月 26 日 22:52:42 boggan systemd[1]: mariadb.service: 失败，结果为“超时”`

第一systemd行有点像“嗯，呃”。我知道它超时了。第二行systemd，mysqld在行后有点令人费解，因为它做事实上启动了。依赖于数据库的应用程序（特别是 OwnCloud）可以正常工作……无论 MariaDB 何时启动。

另一个问题建议使用time /etc/init.d/mysql start来确定需要多长时间。我反复运行它来确认时间 - 每次都是 90 秒左右几秒。

其他研究让我检查文件权限，这是很好的......此外，它做暂时启动。我已经尽我所能（当然，在 Linux 方面我的能力有限）进行了尝试，但还没有取得任何进展。

所以，问题是......如何让 MariaDB 服务保持运行？

更麻烦的是，写完这个问题后，我让机器继续运行。一周后我又回来了（中间我没有碰过它）。使用完全相同的命令，sudo /etc/init.d/mysql start成功了。mysql 守护进程启动并运行；它返回了一个[ ok ]报告。为了实验，我重新启动了机器，然后又回到了开始的地方。

如果有关系的话，输出journalctl -xe是：

4 月 2 日 23:51:44 boggan systemd[1]: 已停止提前读取所需文件。
-- 主题：单元 ureadahead.service 已完成关闭
-- 定义者：systemd
-- 支持：http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
——单元 ureadahead.service 已完成关闭。
4月2日 23:51:55 boggan mysqld[2645]: 2016-04-02 23:51:55 140386161068800 [注意] InnoDB: 在线 DDL : 开始
4月2日 23:51:55 boggan mysqld[2645]: 2016-04-02 23:51:55 140386161068800 [注意] InnoDB: Online DDL : 开始读取表的聚集索引并创建临时文件
4月2日 23:51:55 boggan mysqld[2645]: 2016-04-02 23:51:55 140386161068800 [注意] InnoDB: Online DDL : 结束读取表的聚集索引并创建临时文件
4月2日 23:51:55 boggan mysqld[2645]: 2016-04-02 23:51:55 140386161068800 [注意] InnoDB: 在线 DDL : 已完成
4月2日 23:51:55 boggan mysqld[2645]: 2016-04-02 23:51:55 140386161068800 [注意] InnoDB: 在线 DDL : 已完成
4月02日 23:52:06 boggan dbus[713]: [系统] 无法激活服务“org.bluez”: 超时
4 月 2 日 23:52:37 boggan systemd[1]: mariadb.service: 启动操作超时。正在终止。
4月2日 23:52:37 boggan mysqld[2645]: 2016-04-02 23:52:37 140386097400576 [注意] /usr/sbin/mysqld: 正常关闭
4月2日 23:52:37 boggan 内核：审计：类型=1400 审计（1459655557.935:31）：apparmor=“DENIED”操作=“sendmsg”配置文件=“/usr/sbin/mysqld”名称=“/run/systemd/notify”pid=2645 comm=“mysqld”requested_mask=“w”denied_mask=“w”fsuid=122 ouid=0
4月2日 23:52:37 boggan 审计[2645]: AVC apparmor="DENIED" 操作="sendmsg" 配置文件="/usr/sbin/mysqld" 名称="/run/systemd/notify" pid=2645 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=122 ouid=0
4 月 2 日 23:52:37 boggan mysqld[2645]: 2016-04-02 23:52:37 140386097400576 [注意] 事件调度程序: 清除队列。0 个事件
4月2日 23:52:37 boggan mysqld[2645]: 2016-04-02 23:52:37 140385225500416 [注意] InnoDB: FTS 优化线程退出。
4月2日 23:52:37 boggan mysqld[2645]: 2016-04-02 23:52:37 140386097400576 [注意] InnoDB: 正在开始关闭...
4月2日 23:52:39 boggan mysqld[2645]: 2016-04-02 23:52:39 140386097400576 [注意] InnoDB: 关闭完成；日志序列号 3360838
4月2日 23:52:39 boggan mysqld[2645]: 2016-04-02 23:52:39 140386097400576 [注意] /usr/sbin/mysqld: 关闭完成
4月2日 23:52:39 boggan 内核：审计：类型=1400 审计（1459655559.419:32）：apparmor=“DENIED”操作=“sendmsg”配置文件=“/usr/sbin/mysqld”名称=“/run/systemd/notify”pid=2877 comm=“mysqld”requested_mask=“w”denied_mask=“w”fsuid=122 ouid=0
4月2日 23:52:39 boggan 审计[2877]: AVC apparmor="DENIED" 操作="sendmsg" 配置文件="/usr/sbin/mysqld" 名称="/run/systemd/notify" pid=2877 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=122 ouid=0
4月2日 23:52:39 boggan 审计[2645]: AVC apparmor="DENIED" 操作="sendmsg" 配置文件="/usr/sbin/mysqld" 名称="/run/systemd/notify" pid=2645 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=122 ouid=0
4月2日 23:52:39 boggan 内核：审计：类型=1400 审计（1459655559.419:33）：apparmor=“DENIED”操作=“sendmsg”配置文件=“/usr/sbin/mysqld”名称=“/run/systemd/notify”pid=2645 comm=“mysqld”requested_mask=“w”denied_mask=“w”fsuid=122 ouid=0
4 月 2 日 23:52:39 boggan systemd[1]: 无法启动 MariaDB 数据库服务器。
-- 主题：单元 mariadb.service 已失败
-- 定义者：systemd
-- 支持：http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- 单元 mariadb.service 已失败。
--
——结果失败了。
4 月 2 日 23:52:39 boggan systemd[1]: mariadb.service: 设备进入故障状态。
4 月 2 日 23:52:39 boggan systemd[1]: mariadb.service: 失败，结果为“超时”。

答案1

从 mysql 升级到 mariadb 后，我遇到了同样的问题。奇怪的是，服务 mariadb start 因超时而失败（无论是在系统启动时还是手动），而服务 mysql start 却成功了。

给出的解释是特级警司是正确的，但是修正对我来说不起作用。

$ sudo aa-complain /usr/sbin/mysqld
Setting /usr/sbin/mysqld to complain mode.

ERROR: /etc/apparmor.d/usr.sbin.mysqld contains no profile

因此我禁用了该配置文件（使用 aa-disable，这似乎相当于财阀的解决方案）

$ sudo aa-disable /usr/sbin/mysqld
Disabling /usr/sbin/mysqld.

我也禁用了 mysqld-akonadi 和 mysqld-digikam。

装甲重装是不够的，所以我必须重启并且 mariadb 启动正常。

答案2

apparmor 是罪魁祸首。尽管内容/etc/apparmor.d/usr.sbin.mysqld只是评论，并声称它的存在是为了防止 apparmor 被 MariaDB 卡住，但事实确实如此。

AppArmor 和 MySQLOracle 博客上的信息提供了我所需要的信息，帮助我弄清楚到底发生了什么。

sudo aa-status向您展示 apparmor 正在做什么；什么实际上有一个强制执行的策略，而不是什么只是设置为抱怨。

sudo apt-get install apparmor-utils添加了一些命令，使 apparmor 配置文件更容易处理，例如...

sudo aa-complain /usr/sbin/mysqld将配置文件从“强制”变为投诉。（aa-enforce将其恢复。）

完成后，sudo service apparmor reload重新启动 apparmor，然后瞧...sudo /etc/init.d/mysql start就可以工作了，并且服务器保持运行。

答案3

我必须完全禁用 apparmor 中的 mysql。aa-complain 对我没有任何作用。所以...

ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/

然后重启

答案4

一个简单的解决方案是删除任何未知的 AppArmor 配置文件：

aa-remove-unknown
Removing '/snap/core/6350/usr/lib/snapd/snap-confine'
Removing '/usr/sbin/mysqld'

有用！

相关内容