解决Centos/Mysqld 重启或关机时间慢问题

项目场景：

提示：centos 8测试环境中，将通过二进制安装的服务添加到systemd服务管理中，并对其进行测试，看是否能满足线上需求，即开机自动启动。由于添加到systemd的服务并未达到想象中的开机自启动的效果，因此需要对服务器进行不断的重启。

---

问题描述

提示：通过使用reboot、shutdown -h now、init 0 等关机重启命令后，系统界面直接黑屏，并没有任何提示信息，但是通过ping 主机的IP地址，一直的是通的，端口是不通的，通过多次重启关机，发现操作系统从执行完关机重启命令后，将近5分钟的时间系统才能正常登录，在此期间ping ip地址一直是通，，直到启动系统时会丢3~4ping包，说明操作系统并未真正的进行关机而是卡在停止某个服务中。

---

原因分析：

提示：系统启动后，逐一将相关服务通过systemctl stop xx.service，在进行启动，看中间的时间间隔是否过长，同时使用journalctl 命令进行查询上次重启日志信息。

1、配置journalctl，否则将会出现以下报错信息：

2、配置如下：

# 修改配置文件
# sed -i 's/#Storage=auto/Storage=auto/g' /etc/systemd/journald.conf 

# 修改后
# grep 'Storage' /etc/systemd/journald.conf
 Storage=auto

# 创建journal日志目录
# mkdir /var/log/journal  如果已经有了就不用创建

# 重启journald.service
# systemctl restart systemd-journald.service

3、 journal日志设置完毕后，对服务进行重启操作，并使用journal -rb -1 查看日志得出：

4、查询到系统重启或者关闭时，系统卡在停止mariadb服务上，重点对mariadb进行检查，可登录到mysql服务中进行查看；

show variables like '%innodb_buffer_pool%';

 

 其中参数：innodb_buffer_pool_dump_at_shutdown，即当数据库实例或者正常关闭的时候，将缓冲池(buffer_pool)的数据导入保存到磁盘文件（即数据库的数据目录下的ib_buffer_pool文件）数据库启动后会自动加载到将缓冲池(buffer_pool)中

详情可查看官方文档：MySQL :: MySQL 8.0 Reference Manual :: 15.8.3.6 Saving and Restoring the Buffer Pool State

---

解决方案：

提示：关闭缓冲池开机自动加载，同时开启缓冲池开机手动加载，详情如下：

1、关闭 缓冲池自动加载，innodb_buffer_pool_load_at_startup=0

        修改/etc/my.cnf 添加 innodb_buffer_pool_load_at_startup=0 选项，重启mysqld服务即可。

        为啥不能在数据库直接修改？因为 innodb_buffer_pool_load_at_startup是只读文件，所以只能在配置文件修改：

 2、开启缓冲池手动加载  innodb_buffer_pool_load_now =1

MariaDB [(none)]> SET GLOBAL innodb_buffer_pool_load_now=1;
Query OK, 0 rows affected (0.000 sec)

MariaDB [(none)]> SHOW STATUS LIKE 'Innodb_buffer_pool_load_status';
+--------------------------------+--------------------------------------------------+
| Variable_name                  | Value                                            |
+--------------------------------+--------------------------------------------------+
| Innodb_buffer_pool_load_status | Buffer pool(s) load completed at 220721 10:00:09 |
+--------------------------------+--------------------------------------------------+
1 row in set (0.002 sec)

至此，数据库/操作系统服务重启时间长的问题进行解决，同时服务器/数据库重启时间慢，相信以上这并不是唯一的原因，重点的还是要根据日志信息进行分析排查，最终解决故障问题。