1Panel清理MySQL binlog防止炸磁盘
虽说我将 Linux 的磁盘空间升级到了 30GiB
但是
image1075×442 19.7 KB
最终我想起了可能是 MySQL 日积月累来的 binlog 占用了太多磁盘
image1298×479 16.6 KB
手动删除
对于使用雨云预装的1Panel（以下简称1p）
在1p中点击“主机 → 文件”
image881×518 27.6 KB
点击上方的地址栏（红圈部分）后面的空白部分（黄圈部分）
image893×518 34.7 KB
全选并删除所有内容后，将下方的路径粘贴到其中并回车
/opt/1panel/apps/mysql/mysql/data
向下滑动
image1563×916 59 KB
点击“binlog.index”（二进制日志索引）进入编辑模式
删除除最后有内容的一行外的其他内容
点击确认保存文件
之后删除当前目录下的binlog文件即可，但切记勿删正在使用的binlog（即上步没有删除的那行中的文件名）【可删除：绿圈；不可删除：红圈】
image1562×511 46.5 KB
配置过期时间自动删除
首先需要连接到MySQL数据库
在1p中点击数据库，点击连接信息，将弹出窗口中的root密码复制下来
点击“容器”，找到带有MySQL字样的，点击后方的终端
image1809×960 90.2 KB
image896×404 4.54 KB
点击连接后，输入
mysql -u root -p
使用Ctrl Shift V将复制的密码粘贴到里面，然后回车即可连接（粘贴后直接回车，密码不会回显出来）
出现mysql> 后，输入
show variables like '%binlog_expire%';
可以查询当前binlog的清理配置
binlog_expire_logs_auto_purge：是否自动清理
binlog_expire_logs_seconds：多长时间清理一次，单位为秒（MySQL 8）
expire_logs_days：多长时间清理一次，单位为天（MySQL 7或更低版本）
若在启动时binlog_expire_logs_seconds和expire_logs_days参数都设置为非0值则使用binlog_expire_logs_seconds值，expire_logs_days值则失效并对其发出告警信息，即binlog_expire_logs_seconds的优先级大于expire_logs_days
默认的binlog过期时间为2592000秒，也就是30天，但对于部署了蜜罐攻击诱捕系统的人来说，过多的数据库写入会导致binlog急剧增大，不得不减少binlog保留时间
使用以下命令可以将binlog过期时间设置为1天（MySQL 8）
set global binlog_expire_logs_seconds=86400; set persist binlog_expire_logs_seconds=86400;
返回了Query OK, 0 rows affected (0.00 sec)
代表查询成功，0行受影响
此命令同时支持动态计算（以下为60秒60分24小时，得出一天的秒数并持久化进配置文件）
set global binlog_expire_logs_seconds=60*60*24; set persist binlog_expire_logs_seconds=60*60*24;
注意，这仅仅只是个动态计算，你无需考虑顺序或是否存在第61秒（如下）
set global binlog_expire_logs_seconds=24*60*61; set persist binlog_expire_logs_seconds=24*60*61;
再次查询binlog过期时间可以看到已经被更改
手动刷新过期日志：
flush logs;
使用此命令可以查询到所有和binlog相关的配置
show variables like '%binlog%';
image453×615 10.5 KB
一些建议
如果需要恢复某个数据库备份（特别是从一台服务器导出导入到另一台服务器的情况下）会造成大量的MySQL查询，有时会产生巨量的binlog日志，对此建议在执行大事物前关闭 set session sql_log_bin=0; （默认是开启的）。千万不要不假思索的加上 global 修饰符（set global sql_log_bin=0)，这样会导致所有在Master数据库上执行的语句都不记录binlog，这肯定不是你想要的结果
sync_binlog
取值为0：mysql 自己不主动同步，依赖操作系统本身的sync机制不定期把文件内容刷新到磁盘，性能最佳（对于追求极致性能的可以考虑）
取值为1：每次事务提交后将 binlog_cache 中的数据强制写入磁盘 bin log日志中，是最慢的，但是最安全（默认）
取值 >1：当进行n次事务提交后，mysql 将 binlog_cache 中的数据强制写入磁盘中（推荐小网站设置为100-300左右，中型网站设置为500-700左右，大型网站设置为1000左右）
当 sync_binlog 和 innodb_flush_log_at_trx_commit 都为 1 时是最安全的，在 mysqld 服务崩溃或者服务器主机 crash 的情况下，已提交的事务是不会丢失数据的
【参考 MySQL :: MySQL 8.2 Reference Manual :: 17.1.6.4 Binary Logging Options and Variables】