重启Linux服务器上的数据库，核心操作是通过系统服务管理器或数据库自带工具来执行，而不是直接重启整个操作系统。多数情况下，你只需一条 systemctl restart 命令即可完成，但具体选哪个命令、怎么做最安全，取决于你用的是MySQL、PostgreSQL还是其他数据库，以及服务器上跑的是不是关键业务。
重启前必须做的三件准备工作
很多人上来就敲重启命令,结果数据库起不来了才后悔，先花两分钟确认以下三件事，能避免绝大多数故障。
确认数据库进程到底叫什么名字
Linux下数据库的服务名不一定是mysql或postgresql，比如装了MariaDB，服务名可能是mariadb；用Docker跑的数据库，进程又在容器里，先执行下面这条命令看看当前有哪些数据库进程在跑：
ps aux | grep -E 'mysql|postgres|mongo|redis'
确认进程名后,再用systemctl status查服务状态，
systemctl status mysqld
如果提示找不到服务,试试mysql或者mariadb，行业共识认为，这一步能帮你避免”服务名写错导致重启失败”这种低级错误。
检查当前连接数和未提交事务
直接重启数据库,正在执行的写操作会被强制中断，可能造成数据文件损坏，重启前，登录数据库查一下活跃连接数，以MySQL为例：
SHOW PROCESSLIST;
看有没有Sleep状态很久的长连接，或者Query状态正在跑的大事务，如果有重要的批处理任务在跑，等它跑完再重启。
备份关键数据或至少打个快照
只要是重启生产库，备份这一步不能省。 对云服务器来说，最快的办法是去云控制台给磁盘打个快照，耗时也就一两分钟，物理机的话，至少把配置文件和数据目录做个tar包，真心建议你别跳过这步，因为数据库启动失败后的恢复工作，远比备份本身痛苦。
mysql重启命令linux环境下的三种实操方式
MySQL系数据库在Linux上的重启方式,根据安装来源不同，分三种情况。
systemctl命令（CentOS 7+/Ubuntu 16.04+）
这是最常见的场景,90%的机器都用这种方式：
systemctl restart mysqld
如果服务名不对,试试：
systemctl restart mysql
执行完看一下状态,确认重启成功：
systemctl status mysqld
看到active (running)字样就说明重启完成了，这里提醒一句：restart等于先停再启，如果只是想让配置生效，用reload更平滑，不会断开现有连接。
service命令（老版本系统）
有些老机器还在用SysV init，没有systemctl，这时用：
service mysqld restart
或者：
/etc/init.d/mysqld restart
这种方式的输出是传统的Starting MySQL... [OK]格式，看到OK就说明成功了。
docker容器中的MySQL重启
如果你的数据库跑在容器里,思路完全不同，先看容器名：
docker ps | grep mysql
然后重启容器：
docker restart mysql_container_name
注意，这种方式重启的是整个容器，相当于把MySQL进程直接杀掉再启动，不适合有大量连接的生产环境。 更优雅的方式是进入容器内部，用mysqladmin命令平滑关闭，再启动。
PostgreSQL数据库重启命令对比：systemctl与pg_ctl
PostgreSQL的重启方式和MySQL有较大差别,尤其是它自带的pg_ctl工具，提供了更细粒度的控制。
systemctl方式（适合大多数场景）
systemctl restart postgresql-14
注意服务名通常带版本号,可能是postgresql-14、postgresql-13等，不确定就先systemctl list-unit-files | grep postgres查一下。
pg_ctl方式（适合需要精确控制的场景）
PostgreSQL的安装目录下自带重启工具,以CentOS为例，先切换到postgres用户：
su - postgres
然后使用pg_ctl执行重启：
/usr/pgsql-14/bin/pg_ctl restart -D /var/lib/pgsql/14/data/
-D后面跟的是数据目录，不同系统路径不一样，可以在配置文件里看到。pg_ctl的restart模式会先做一次快速关闭，如果有关联的事务正在写入，进程会等待这些事务完成，从源头上避免数据错乱。 这也是很多DBA偏爱这种方式的原因。
| 对比维度 | systemctl restart | pg_ctl restart |
|---|---|---|
| 操作门槛 | 低，一条命令搞定 | 中，需要知道数据目录路径 |
| 对未完成事务的处理 | 直接终止，有风险 | 等待当前事务结束后关闭 |
| 适用场景 | 测试库、开发库、业务低峰期 | 生产环境、有长事务在跑 |
| 恢复速度 | 快 | 相对稍慢 |
数据库服务重启失败的排查思路
重启数据库最怕的就是敲完命令,结果服务起不来了，别慌，按照下面的顺序排查。
先看错误日志文件
数据库的错误日志是最直接的线索,MySQL在/var/log/mysqld.log，PostgreSQL在数据目录下的pg_log文件夹里，用tail命令看最后几十行：
tail -n 100 /var/log/mysqld.log
最常见的错误是磁盘空间满了或者数据目录权限不对，删掉几天前的二进制日志，或者chown -R mysql:mysql /var/lib/mysql修复权限，通常能解决问题。
检查配置文件是否有语法错误
改过my.cnf或postgresql.conf后重启失败，大概率是配置写错了，可以用官方工具验证一下，MySQL的验证命令：
mysqld --validate-config
PostgreSQL的验证方式：
/usr/pgsql-14/bin/pg_ctl -D /var/lib/pgsql/14/data/ -f config check
如果验证通过,再尝试启动，基本就成功了。
看看端口被谁占用了
有时候数据库进程没完全退出,新进程启动时发现端口被占，直接退出，排查命令：
ss -lntp | grep 3306
没有输出就说明端口没被占用,如果有输出，用kill -9 PID杀掉残留进程，再执行重启命令。
生产环境数据库重启的操作纪律
在开发环境敲命令随便重启没问题,但生产库是另一回事，多数情况下，操作失误导致的数据库启动失败，远比数据库本身出故障更麻烦。
选择业务低谷期并设置超时保护
晚上凌晨两点到五点，通常是重启数据库的最佳窗口。 这个时间段业务流量最低，即使出现意外，影响面也最小，执行重启时，用nohup包裹命令并记录日志：
nohup systemctl restart mysqld > /tmp/restart.log 2>&1 &
这样即使你的SSH连接断开了,重启操作也会继续执行完。
主从架构下先重启从库
如果你的数据库有主从复制,顺序应该是：先重启从库，等同步追平后再重启主库，原因很简单从库出问题不影响主库对外服务，而主库重启失败意味着整个业务停摆，具体操作时，在从库上执行：
systemctl restart mysqld
然后登录从库检查同步状态：
SHOW SLAVE STATUS\G;
关注Seconds_Behind_Master这个字段，数值变为0说明追平了，再去操作主库。
用数据库命令实现在线重启
很多数据库支持在线重启命令,不停机也能让配置生效，MySQL里可以用：
SET GLOBAL max_connections = 500;
这种在线调整的方式,动态修改参数，不需要重启进程，能用这种方式解决的，就尽量不要走重启这条路，PostgreSQL同理，很多参数都能用ALTER SYSTEM在线修改并立即生效。
常见问题解答
Linux下怎么确认数据库真的重启成功了？
执行systemctl status mysqld查看服务状态，输出中包含active (running)表示服务正常运行，再用mysqladmin ping，看到返回mysqld is alive，说明数据库已经能正常接受连接了。
重启MySQL时提示“Job for mysqld.service failed”怎么处理？
用systemctl status mysqld -l查看完整报错信息，绝大多数情况是数据目录空间不足或配置文件写错，先通过df -h确认磁盘余量，再用mysqld --validate-config检查配置，按错误提示修复后重新启动。
远程重启数据库和本地重启有什么区别？
远程操作通常通过SSH登录执行命令,本质上和本地操作没有区别，但远程登录受网络稳定性影响，如果重启过程中网络断开，命令可能被中断，生产环境建议用screen或nohup保持命令持续执行，避免SSH断开导致重启流程中断，远程重启前务必确认自己有权限修改数据库配置文件，防止启动时读取了不完整的配置。
重启数据库是一个日常操作,但日常不代表可以随便乱来，记住一条核心原则：能在线改的不要重启，非要重启的先备份，重启完成的必须检查状态。 按这个思路操作，大部分重启相关的坑都能避开。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/787658.html
