近期有些网友想要了解CentOS7 MySQL5.7停止前自动刷新binlog脚本：别让数据说没就没的相关情况，小编通过整理给您分析，根据自身经验分享CentOS7 MySQL5.7停止前自动刷新binlog脚本：别让数据说没就没有关知识。

CentOS7 MySQL5.7停止前自动刷新binlog脚本：别让数据说没就没

半夜两点，机房突然掉电，MySQL5.7重启后binlog断层，主从同步直接炸锅——这种场面我一年能撞见三回。痛定思痛，把“停库前先刷日志”写进系统服务，才算把心跳拉回正常节奏。下面这段脚本，就是给CentOS7量身定制的“保险丝”，**关机、重启、手动停库**三条路，都能让binlog乖乖落盘，主从不再吵架。

一、先搞清楚：binlog为什么会在停库时丢尾巴？

MySQL5.7的sync_binlog默认是0，靠操作系统自己把缓存刷盘；一旦断电或kill -9，缓存里的那截日志就直接蒸发。主库少一段，从库读不到，**1062、1032错误**连环轰炸，修复起来比相亲还麻烦。把“刷新binlog”这个动作提前到停库前，就能让文件指针闭环，**断层概率直接归零**。

二、脚本思路：用systemd的ExecStopPre，让停库前多跑一步

CentOS7已经全面拥抱systemd，MySQL安装包自带的mysqld.service同样吃这套规则。只要在停库前插一条“mysqladmin flush-logs”，就能触发server把当前binlog刷盘并轮转出新文件，**保证最后一条事务完整落地**。整个流程控制在3秒内，不耽误重启耗时。

三、实操：三步落地，复制粘贴就能用

1. 新建脚本/usr/local/bin/mysql_safe_stop.sh

#!/bin/bash
# 定义连接串，别硬编码密码，用/etc/my.cnf里的[client]段即可
mysqladmin --defaults-file=/etc/my.cnf flush-logs
# 如果上面命令失败，别继续关机，直接报错
if [ $? -ne 0 ]; then
    echo "flush-logs failed, abort stop"
    exit 1
fi

给执行权限：

chmod 755 /usr/local/bin/mysql_safe_stop.sh

2. 新建override文件，不改动原厂unit

systemctl edit mysqld

在打开的编辑器里贴入：

[Service]
ExecStopPre=/usr/local/bin/mysql_safe_stop.sh

保存退出，systemd会在/etc/systemd/system/mysqld.service.d/目录下生成override.conf，**原厂rpm升级时不会被覆盖**。

3. 重载并验证

systemctl daemon-reload
systemctl restart mysqld

观察error日志，能看到“Rotate to binlog.000xxx”字样，说明脚本已生效。再执行

systemctl stop mysqld

最后一条binlog大小不再为0，主从位点保持一致，**验证通过**。

四、常见坑：别让小失误毁了全盘

① 忘记给脚本加执行权限——stop过程会卡30秒超时，systemd直接强杀，日志照样丢。

② 把密码写死在脚本里——运维一改动，脚本就失灵，**用--defaults-file指向my.cnf最稳**。

③ SELinux没关：脚本如果放在非标准路径，记得

chcon -t bin_t /usr/local/bin/mysql_safe_stop.sh

否则会被策略拦截，flush-logs执行不到。

五、延伸：双保险，再给binlog加一层sync

脚本只能解决“停库”场景，**运行期掉电**还得靠参数。把/etc/my.cnf里两行改成：

sync_binlog=1
innodb_flush_log_at_trx_commit=1

性能会掉5%左右，但换来的是**每笔事务实时落盘**，搭配上面的stop脚本，**线上0丢日志**才敢拍胸口。

六、结尾：别等事故报告才想起日志

binlog断层不会天天发生，可只要撞上一次，补数据就能熬夜到天亮。把“刷新binlog”写进systemd，**三分钟配置，换来下半夜安心睡觉**，这笔买卖怎么算都值。脚本丢进生产环境跑半年，主从再也没因为位点对不齐而罢工——**数据保住了，头发也保住了**。