Question

我在安装了MariaDB的服务器上遇到了一些问题。

mariadb 进程几天前第一次突然停止工作，当我尝试重启它时

sudo service mariadb restart

我得到了这个输出

Redirecting to /bin/systemctl restart mariadb.service
Job for mariadb.service failed because the control process exited with error cod                                                                                                     e. See "systemctl status mariadb.service" and "journalctl -xe" for details.
[root@web-customer-01 ~]# systemctl status mariadb.service
● mariadb.service - MariaDB database server
   Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Tue 2018-02-13 15:43:56 UTC; 24s ago
  Process: 10529 ExecStartPost=/usr/libexec/mariadb-wait-ready $MAINPID (code=exited, status=1/FAILURE)
  Process: 10528 ExecStart=/usr/bin/mysqld_safe --basedir=/usr (code=exited, status=0/SUCCESS)
  Process: 10498 ExecStartPre=/usr/libexec/mariadb-prepare-db-dir %n (code=exited, status=0/SUCCESS)
 Main PID: 10528 (code=exited, status=0/SUCCESS)

Feb 13 15:43:54 web-customer-01.customer.it systemd[1]: Starting MariaDB database server...
Feb 13 15:43:54 web-customer-01.customer.it mariadb-prepare-db-dir[10498]: Database MariaDB is probably initialized in /var/lib/mysql already, nothing is done.
Feb 13 15:43:54 web-customer-01.customer.it mysqld_safe[10528]: 180213 15:43:54 mysqld_safe Logging to '/var/log/mariadb/mariadb.log'.
Feb 13 15:43:54 web-customer-01.customer.it mysqld_safe[10528]: 180213 15:43:54 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
Feb 13 15:43:56 web-customer-01.customer.it systemd[1]: mariadb.service: control process exited, code=exited status=1
Feb 13 15:43:56 web-customer-01.customer.it systemd[1]: Failed to start MariaDB database server.
Feb 13 15:43:56 web-customer-01.customer.it systemd[1]: Unit mariadb.service entered failed state.
Feb 13 15:43:56 web-customer-01.customer.it systemd[1]: mariadb.service failed.

作为临时解决方案，我发现正在删除这些文件，服务会重新启动，但我不确定它是否是一个好的解决方案

/var/lib/mysql/ib_logfile0
/var/lib/mysql/ib_logfile1

我在mariadb日志中发现了很多这些行

180213 15:53:29  InnoDB: Error: page 16392 log sequence number 19972774982
InnoDB: is in the future! Current system log sequence number 731248348.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: for more information.

然后，正如上面链接中所提到的，我在 my.cnf 中添加了 innodb_force_recovery

[mysqld]
innodb_force_recovery = 1

我试图调查此问题，但我对可能的原因没有任何想法，因此我无法找到正确的解决方案。

- 的修改

这是我的/etc/my.cnf （事实上我在这些日子里添加了 innodb_force_recovery ）

[mysqld]
innodb_force_recovery = 1
innodb_buffer_pool_size=256M
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under a different user or group,
# customize your systemd unit file for mariadb according to the
# instructions in http://fedoraproject.org/wiki/Systemd
skip-name-resolve

[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid

#
# include all files from the config directory
#
!includedir /etc/my.cnf.d

[client]
port = 3306
socket = =/var/lib/mysql/mysql.sock

Answer 1

我前段时间遇到过这个问题，但我不确定它是如何解决的。

据我所知，它用于恢复的InnoDB das 3文件

ibdata1中
ib_logfile0
ib_logfile1

如果删除它们，那么DB很可能会启动但是如果创建这些文件的目录与其他与DB相关的目录具有不同的时间戳，则会抛出错误，因为它会检查目录的时间戳以及备份时的时间戳。（如果这有意义的话）

我发现这可能会有所帮助：

恢复模式

模式说明

0 InnoDB正常运行时的默认模式。在MariaDB 10.2.7之前，它是唯一允许更改数据的模式。从MariaDB 10.2.7开始，innodb_force_recovery＆lt; = 3。

允许写入事务

1（SRV_FORCE_IGNORE_CORRUPT）允许服务器继续运行，即使检测到损坏的页面也是如此。它通过使基于重做日志的恢复忽略某些错误（例如丢失数据文件或损坏的数据页）来实现。将跳过受影响的文件或页面的任何重做日志。您可以通过获取SELECT * FROM table_name语句来跳过损坏的索引和页面来促进转储表。

2（SRV_FORCE_NO_BACKGROUND）阻止主线程运行，防止在清除期间发生崩溃。不会执行清除，因此撤消日志将继续增长。

3（SRV_FORCE_NO_TRX_UNDO）在崩溃恢复后不会回滚事务。不影响当前活动事务的回滚。从MariaDB 10.2.7开始，还将阻止一些生成撤消的后台任务运行。由于恢复的未完成事务的回滚被阻止，这些任务可能会锁定等待。

4（SRV_FORCE_NO_IBUF_MERGE）不计算表统计信息并阻止插入缓冲区合并。

5（SRV_FORCE_NO_UNDO_LOG_SCAN）将未完成的事务视为已提交，并且在启动时不会查看撤消日志。

6（SRV_FORCE_NO_LOG_REDO）不会执行重做日志前滚作为恢复的一部分。在此模式处于活动状态时，运行需要索引的查询可能会失败。但是，如果表转储仍然导致崩溃，您可以尝试使用SELECT * FROM tab ORDER BY primary_key DESC在损坏的部分之后转储所有数据部分。

所以你可以尝试不同的模式，看看是否有帮助。

Answer 2

innodb_buffer_pool_size=256M对于仅1GB的RAM来说可能太大了。改为64M。您是否在服务器中运行任何其他应用程序？那也会严重地制造麻烦。

/etc/my.cnf.d中的内容是什么？我们需要查看所有配置设置，以找出调整得太大的其他内容。

或者你可以考虑获得更多的RAM。

Answer 3

就我而言，删除 innodb_additional_mem_pool_size = 128M 做到了。

MariaDB服务连续无法启动

3 个答案: