Mysql MariaDB服务持续无法启动

我在安装了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

我试图调查这个问题，但我不知道可能的原因，因此我无法找到正确的解决方案

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

-- 编辑

这是我的/etc/my.cnf （obv I最近增加了innodb_force_recovery）

---

我不久前遇到过这个问题，但我不确定它是如何修复的

据我所知，InnoDB das使用3个文件进行恢复

• ibdata1
• ib_日志文件0
• ib_日志文件1

如果删除这些文件，数据库很可能会启动，但如果创建这些文件的目录与其他与数据库相关的目录具有不同的时间戳，则会抛出错误，因为它会检查备份目录时的时间戳。（如果有道理的话）

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

恢复模式

模式描述

---

InnoDB正常运行时的默认模式为0。在MariaDB 10.2.7之前，它是唯一允许更改数据的模式。从MariaDB 10.2.7开始，innodb_force_recovery允许写事务

innodb_buffer_pool_size=256M

对于仅1GB的RAM来说可能太大了。换成64M。您是否在服务器上运行其他应用程序？这也会使事情变得非常棘手

/etc/my.cnf.d

中有什么内容？我们需要查看所有的配置设置，以找出还有哪些设置调整得太大

或者您可以考虑增加RAM。

在我的情况下，删除

innodb\u附加\u成员\u池大小=128M

---

成功了。

哦，天哪，你真的在不知道这些文件的用途的情况下删除了这些文件吗？我也喜欢生活在危险中！！是@Hackerman，但在删除这些文件之前，我有几天前的备份。我理解它的重要性，但这是让服务器重新联机的唯一方法。您有多少RAM？向我们展示您的

my.cnf

。像您这样的一些问题是由于配置不当造成的。@RickJames这是一个只有1GB内存的数字海洋VPS，我将在帖子中添加my.cnf。

[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