1Panel清理MySQL binlog防止炸磁盘

虽说我将 Linux 的磁盘空间升级到了 30GiB

但是

image

image1075×442 19.7 KB

最终我想起了可能是 MySQL 日积月累来的 binlog 占用了太多磁盘

image

image1298×479 16.6 KB

手动删除

对于使用雨云预装的1Panel(以下简称1p)
在1p中点击“主机 → 文件”

image

image881×518 27.6 KB

点击上方的地址栏(红圈部分)后面的空白部分(黄圈部分)

image

image893×518 34.7 KB

全选并删除所有内容后,将下方的路径粘贴到其中并回车

 

/opt/1panel/apps/mysql/mysql/data

向下滑动

image

image1563×916 59 KB

点击“binlog.index”(二进制日志索引)进入编辑模式

image

删除除最后有内容的一行外的其他内容

image

点击确认保存文件

之后删除当前目录下的binlog文件即可,但切记勿删正在使用的binlog(即上步没有删除的那行中的文件名)【可删除:绿圈;不可删除:红圈】

image

image1562×511 46.5 KB

配置过期时间自动删除

首先需要连接到MySQL数据库
在1p中点击数据库,点击连接信息,将弹出窗口中的root密码复制下来

image

点击“容器”,找到带有MySQL字样的,点击后方的终端

image

image1809×960 90.2 KB

image

image896×404 4.54 KB

点击连接后,输入

 

mysql -u root -p

image

使用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;

image

返回了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过期时间可以看到已经被更改

image

手动刷新过期日志:

 

flush logs;

image

使用此命令可以查询到所有和binlog相关的配置

 

show variables like '%binlog%';

image

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

如果出现任何问题,可以重启数据库并做出如下动作:

574973ac3ee8ca356884b354903d97b9

  • 26
    点赞
  • 23
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值