我的Mariadb是通过yum源安装的,因为服务器本身是我一边放着这个万年不更新的博客,一边跑一些测试程序的地方,所以是不是手欠去执行一下 yum update 。
然后过一阵子就发现,博客打不开了,博客又打不开了……
一看提示,都是数据库连不上了。这个囧啊,然后每当出现这个问题就得花好久时间去查,mysql到底咋啦。出了啥问题。
基本现象就是,执行完 service mysql start
之后,报错,执行 service mariadb restart
也报错。
看 systemctl status mariadb.service
以及 journalctl -xe
去看错误提示,都很莫名其妙。(现场没有记录下来,只能简单描述了)
例如:
- can’t create test file xxxxx.lower-test
- failed to set environment: access denied
- [system] rejected send message, 2 matched rules; type=”method_call”, sender=”:1.203″ (uid=1000 pid=4064 comm=”systemctl unset-environment
诸如此类的错误。
百度反正没给我啥有价值的帮助,后来我想了下,我的数据文件移动到了 /home/{user}
目录下,因为购买的服务器数据盘都挂载到了 /home
目录,系统盘一般都很小,而默认安装路径担心直接磁盘就满了。
而因为换了目录,所以也没有使用默认的 mysql 用户去访问数据库,直接用了目录对应的用户帐号。然后就导致了每次 update Mariadb ,配置文件就被覆盖一次,造成各种奇怪的问题。
查了很多资料,这些问题是这里造成的
# /usr/lib/systemd/system/mariadb.service
[Service]
User=mysql #每次更新都会改成默认的mysql
Group=mysql
# Prevent writes to /usr, /boot, and /etc
ProtectSystem=full
# Prevent accessing /home, /root and /run/user
ProtectHome=true
# Execute pre and post scripts as root, otherwise it does it as User=
PermissionsStartOnly=true
User 和 Group 比较容易理解,因为我机器上没有建 mysql 这个帐号,所以肯定运行不起来。
之前可能还记得来改这个文件,不过时间长了就把这个给忘记了。然后更新后又傻半天。
如果只改了User和Group,启动的时候很可能会报
原因是 /home
目录在 ProtectHome=true
这个配置的限制下,是没有权限访问的。
然后我终于记起来这个地方了,然后有手欠将 PermissionsStartOnly=true
改成了 PermissionsStartOnly=false
,然后再去 systemctl daemon-reload
,重新尝试启动数据库。
然后,现象就变成了
failed to set environment:
access denied[system] rejected send message, 2 matched rules; type=”method_call”, sender=”:1.203″ (uid=1000 pid=4064 comm=”systemctl unset-environment
看了下原因,在 /usr/lib/systemd/system/mariadb.service
文件中有这么几行
# Execute pre and post scripts as root, otherwise it does it as User=
PermissionsStartOnly=true
# Perform automatic wsrep recovery. When server is started without wsrep,
# galera_recovery simply returns an empty string. In any case, however,
# the script is not expected to return with a non-zero status.
# It is always safe to unset _WSREP_START_POSITION environment variable.
# Do not panic if galera_recovery script is not available. (MDEV-10538)
ExecStartPre=/bin/sh -c "systemctl unset-environment _WSREP_START_POSITION"
ExecStartPre=/bin/sh -c "[ ! -e /usr/bin/galera_recovery ] && VAR= || \
VAR=`cd /usr/bin/..; /usr/bin/galera_recovery`; [ $? -eq 0 ] \
&& systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1"
看到了么,PermissionsStartOnly=true
这个参数直接影响到了执行 ExecStartPre
里面命令的时候的权限。根据说明,这个参数的意思是,用root帐号执行pre脚本,或者是用设置的User帐号执行。我手欠改成 false
了,单独的帐号当然执行不了……
好了,把这几个配置改完了, systemctl daemon-reload
,然后就活过来了。
恩,单独提醒一下,出问题后我没空找原因的时候,又不想服务直接挂着,所以执行 /usr/bin/mysqld_safe &
先把数据库跑起来了。
这样折腾过两次以后,实在烦得很,一个烦的是yum源里面mariadb老更新,另一个烦的是更新了我又有强迫症想更新,第三个烦的是,一更新了我就得来查问题修复数据库……
这时候我在 systemctl status mariadb.service
里面注意到这么几行信息
● mariadb.service - MariaDB 10.3.31 database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/mariadb.service.d
└─migrated-from-my.cnf-settings.conf
OHO,有个配置文件覆盖了配置咯?然后我把修改的配置信息移到了上面提示的文件里面,再试,万事大吉。
撒花~~~
这么看来,下次update,应该不会让我再从失忆中痛苦回忆上次我都干了什么让数据库活过来了