Mariadb 加载，但几分钟后崩溃。从“快照”恢复服务器后发生

【问题标题】：Mariadb loads, but crashes after a couple of minutes. Happened after server was restored from a "snapshot"Mariadb 加载，但几分钟后崩溃。从“快照”恢复服务器后发生
【发布时间】：2019-03-08 21:08:42
【问题描述】：

我有一个由 OVH 托管的 VPS（Ubuntu Server 18.04）。他们提供快照，应该能够将 VPS 回滚到以前的状态。我以前从未使用过此功能。但我昨晚在开始使用 BTCpay 之前做了一个快照。我非常讨厌安装，所以我决定回滚到快照。

现在我的 Mariadb 安装无法正常工作。服务器上唯一托管的是 Wordpress 多站点。如果我重新启动服务器（或使用 systemctl 启动 Mariadb），它会加载并且我可以访问我所有的 wordpress 站点和管理面板。但是几分钟后，Mariadb 崩溃了。

运行 mysqld_safe --skip-grant-tables 输出：

190308 15:10:20 mysqld_safe Logging to syslog.
190308 15:10:20 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql

这可以让 Wordpress 启动并运行，但显然不是一个安全的解决方案。

这些是/var/log/mysql/error.log中唯一出现的错误，但只有一个条目，而且它们不会在每次 Mariadb 崩溃时重复：

2019-03-08 13:08:24 139897840925824 [ERROR] mysqld: Table './mysql/db' is marked as crashed and should be repaired
2019-03-08 13:08:24 139897840925824 [ERROR] mysql.db: 1 client is using or hasn't closed the table properly

和 CHECK TABLE mysql.db; 输出：

+----------+-------+----------+----------+
| Table    | Op    | Msg_type | Msg_text |
+----------+-------+----------+----------+
| mysql.db | check | status   | OK       |
+----------+-------+----------+----------+
1 row in set (0.00 sec)

到目前为止，我采取的步骤是：

  • 将 mysqldump 用于 'wordpress' 数据库，这是我的数据库 为我的 Wordpress 多站点安装设置。

  • 运行 # mysqlcheck --all-databases，结果全部返回 'OK'

  • 尝试了此处列出的修复 https://stackoverflow.com/a/3322930/8644833 使用 mysqld_safe --skip-grant-tables

    • 启动 Mariadb 后

我对 mysql 不是很好，所以我只是在寻找一种解决方案，让我在不丢失太多数据的情况下重新启动并运行。 我不介意全新安装 Mariadb 并设置新的 Wordpress 数据库，但我不确定如何备份所有数据，这样我就不必重建所有网站。 似乎这应该是可能的，因为网站在 Mariadb 崩溃之前都可以正常工作。

这是我掌握的所有其他相关信息：

dmesg：

[  108.430534] audit: type=1400 audit(1552073977.631:19): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=939 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=111 ouid=0
[  108.534100] audit: type=1400 audit(1552073977.739:20): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=939 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=111 ouid=0
[  108.634399] audit: type=1400 audit(1552073977.839:21): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=939 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=111 ouid=0
[  108.734779] audit: type=1400 audit(1552073977.939:22): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=939 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=111 ouid=0
[  108.835027] audit: type=1400 audit(1552073978.039:23): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=939 comm="mysqld" requested_mask="w"denied_mask="w" fsuid=111 ouid=0
[  108.935311] audit: type=1400 audit(1552073978.139:24): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=939 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=111 ouid=0
[  109.035562] audit: type=1400 audit(1552073978.235:25): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=939 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=111 ouid=0
[  109.136162] audit: type=1400 audit(1552073978.339:26): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=939 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=111 ouid=0
[  110.038191] audit: type=1400 audit(1552073979.243:27): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=939 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=111 ouid=0
[  110.040919] audit: type=1400 audit(1552073979.243:28): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/mysqld" name="run/systemd/notify" pid=939 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=111 ouid=0

systemctl status mariadb.service:

    ● mariadb.service - MariaDB 10.1.38 database server
   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
   Active: failed (Result: timeout) since Fri 2019-03-08 14:39:39 EST; 14min ago
     Docs: man:mysqld(8)
           https://mariadb.com/kb/en/library/systemd/
  Process: 939 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 839 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
  Process: 809 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 770 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
 Main PID: 939 (code=exited, status=0/SUCCESS)

Mar 08 14:38:08 mydomain.com systemd[1]: Starting MariaDB 10.1.38 database server...
Mar 08 14:38:09 mydomain.com mysqld[939]: 2019-03-08 14:38:09 140251492867200 [Note] /usr/sbin/mysqld (mysqld 10.1.38-MariaDB-0ubuntu0.18.04.1) starting as process 939 ...
Mar 08 14:39:37 mydomain.com systemd[1]: mariadb.service: Start operation timed out. Terminating.
Mar 08 14:39:39 mydomain.com systemd[1]: mariadb.service: Failed with result 'timeout'.
Mar 08 14:39:39 mydomain.com systemd[1]: Failed to start MariaDB 10.1.38 database server.

mysql日志：

2019-03-08 14:59:39 140597857991808 [Note] InnoDB: innodb_empty_free_list_algor
ithm has been changed to legacy because of small buffer pool size. In order to 
use backoff, increase buffer pool at least up to 20MB.

2019-03-08 14:59:39 140597857991808 [Note] InnoDB: Using mutexes to ref count b
uffer pool pages
2019-03-08 14:59:39 140597857991808 [Note] InnoDB: The InnoDB memory heap is disabled
2019-03-08 14:59:39 140597857991808 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-03-08 14:59:39 140597857991808 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2019-03-08 14:59:39 140597857991808 [Note] InnoDB: Compressed tables use zlib 1.2.11
2019-03-08 14:59:39 140597857991808 [Note] InnoDB: Using Linux native AIO
2019-03-08 14:59:39 140597857991808 [Note] InnoDB: Using SSE crc32 instructions
2019-03-08 14:59:39 140597857991808 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2019-03-08 14:59:39 140597857991808 [Note] InnoDB: Completed initialization of buffer pool
2019-03-08 14:59:39 140597857991808 [Note] InnoDB: Highest supported file format is Barracuda.
2019-03-08 14:59:39 140597857991808 [Note] InnoDB: 128 rollback segment(s) are active.
2019-03-08 14:59:39 140597857991808 [Note] InnoDB: Waiting for purge to start
2019-03-08 14:59:39 140597857991808 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.42-84.2 started; log sequence number 446057526
2019-03-08 14:59:39 140597857991808 [Note] Plugin 'FEEDBACK' is disabled.
2019-03-08 14:59:39 140597201463040 [Note] InnoDB: Dumping buffer pool(s) not yet started
2019-03-08 14:59:39 140597857991808 [Note] Server socket created on IP: '127.0.0.1'.
2019-03-08 14:59:39 140597857991808 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.1.38-MariaDB-0ubuntu0.18.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Ubuntu 18.04
2019-03-08 15:01:09 140597856737024 [Note] /usr/sbin/mysqld: Normal shutdown
2019-03-08 15:01:09 140597856737024 [Note] Event Scheduler: Purging the queue. 0 events
2019-03-08 15:01:09 140597251774208 [Note] InnoDB: FTS optimize thread exiting.
2019-03-08 15:01:09 140597856737024 [Note] InnoDB: Starting shutdown...
2019-03-08 15:01:09 140597856737024 [Note] InnoDB: Waiting for page_cleaner to finish flushing of buffer pool
2019-03-08 15:01:11 140597856737024 [Note] InnoDB: Shutdown completed; log sequence number 446281568
2019-03-08 15:01:11 140597856737024 [Note] /usr/sbin/mysqld: Shutdown complete

【问题讨论】：

    标签： mysql wordpress ubuntu mariadb vps


    【解决方案1】：

    如果可以的话，我会发表评论，但我认为这太重要了，不能完全跳过。

    服务器快照和数据库备份是不同的东西。问题是快照可能会在某事中间捕获数据库服务器。如果您稍后根据快照重新启动系统，数据库服务器可能会感到困惑。很可能需要几分钟才能发现潜伏的不一致和崩溃。据推测，重新安装间接启动了比平常更积极的清理，从而消除了不一致。有关详细信息并确认我的假设，您可以尝试https://dba.stackexchange.com/。

    展望未来，除了系统快照之外，定期进行数据库备份可能会更好。在制作快照时，将 WordPress 置于只读模式（这并不简单，但有一个插件）也可能有效。 （尽管问这是否可行是合理的。）

    【讨论】：

      【解决方案2】：

      我仍然不知道这个问题的根本原因是什么，但是卸载并重新安装 Mariadb 解决了这个问题。

      特别是我做了：

      # apt-get remove --purge mariadb-server
# apt-get autoremove --purge
# apt-get autoclean

      出现提示时，我选择保留现有数据库。

      然后我重新安装了 Mariadb

      # apt-get install mariadb-server

      在此之后一切正常，我不需要恢复任何数据库。

      上述步骤无效

      完成上述操作后，一切正常，直到系统重新启动或 mariadb-server 重新启动。那么原来的问题又出现了，mariadb服务器正常运行一分钟左右就会崩溃。

      我仍然不知道问题出在哪里。我知道从快照恢复是导致问题的原因，但我不知道 Mariadb 为何或以何种方式破坏。我什至尝试删除 mariadb-server 和所有数据库，但是当它重新安装时，我会遇到同样的问题。

      我厌倦了试图找出问题，所以 我转储了 wordpress 数据库，删除了 mariadb-server 和所有数据库，并安装了 mysql-server。这已解决问题。

      【讨论】：

        猜你喜欢
        • 2015-04-16
        • 2017-10-28
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多
        热门标签
        Java Python linux javascript Mysql C# Docker 算法 前端 SpringBoot Redis Vue spring 设计模式 .net core .net kubernetes c++ 数据库 数据结构 大数据 js 机器学习 微服务 Android Go 程序员 面试 JVM ASP.net core 云原生 人工智能 后端 PHP git CSS golang k8s Nginx Django mybatis 深度学习 多线程 React 架构 devops 爬虫 云计算 Spring Boot LeetCode