场景2：需要binlog的场景
基于昨天讲到的场景1是不需要binlog的场景，文章链接如下：
今天接着讲场景2：需要binlog的场景
关于场景2，简而言之就是需要启用或者已经是启用了binlog的场景，如生产环境中的MySQL主从环境。当日积月累，binlog撑爆磁盘空间的时候，又该如何正确的、安全的进行删除较旧的Binlog文件从而释放空间？笔者分享自身的经验，如有不足之处，还望广大IT圈的盆友指出，我们共同学习、成长。
当binlog文件即将要撑爆磁盘的时候，该如何正确、安全的删除历史的binlog？有2种办法，分别为：
- 利用mysql自身的机制自动删除，也就是通过设置相关参数，让binlog保留多少天，当达到期限就会自动删除
- 手动删除，那么手动删除，又分以下几种情况：
- 找到binlog所在的目录，“暴力”直接删除binlog文件，也就是通过rm命令干它，但注意，一定要同时在mysql-bin.index索引文件中删除对应的条目
- mysql提供的PURGE BINARY LOGS 语句来删除更安全，PURGE的方式会自动更新mysql-bin.index中的条目
- RESET MASTER删除所有的二进制日志文件
因笔者每天时间有限，为了保持文章的高质量，今晚就只对“暴力”直接删除binlog文件的方案进行分析，关于另外2个删除办法，我们明天继续谈谈！
1. 笔者的环境如下图
两台服务器组成的互为主从环境，双向复制，非常简单。意思就是：
- db01是master，它的slave是db02
- db02是master，它的slave是db01
互为主从的环境，需要注意，两边都是需要开启binlog记录，笔者环境中使用了keepalived做高可用，当前VIP被db01进行接管，上层应用连接的是VIP，架构很简单，并没有去做双主可以支持并发写数据的事情，因为这涉及到很多问题需要解决，比如数据的一致性等问题，关于双主如何支持并发写，以后笔者会分享这块的经验，目前笔者的环境只使用一个主库提供服务，另外一个是作为BACKUP。
2. 大部分生产环境的mysql架构
一般生产环境架构要么是：
- 一主、一从，主和从都存在单点
- 如果应用的特点是读多写少，那么可以是一主多从，做读写分离的架构，但主只有1台，存在单点
- 既然主有单点故障的风险，那就部署双主多从，甚至是多主多从的架构
3. “暴力“删除之前需要做的相关检查
1. 检查复制状态
- db01
mysql> show replica status\G; *************************** 1. row *************************** Replica_IO_State: Waiting for source to send event Source_Host: 192.168.11.152 Source_User: syn_b Source_Port: 3306 Connect_Retry: 60 Source_Log_File: mysql-bin.000072 Read_Source_Log_Pos: 22831562 Relay_Log_File: zbx-db01-relay-bin.000046 Relay_Log_Pos: 364 Relay_Source_Log_File: mysql-bin.000072 Replica_IO_Running: Yes Replica_SQL_Running: Yes ...
- db02
mysql> show replica status\G; *************************** 1. row *************************** Replica_IO_State: Waiting for source to send event Source_Host: 192.168.11.151 Source_User: syn_a Source_Port: 3306 Connect_Retry: 60 Source_Log_File: mysql-bin.000071 Read_Source_Log_Pos: 22806499 Relay_Log_File: zbx-db02-relay-bin.000102 Relay_Log_Pos: 18710090 Relay_Source_Log_File: mysql-bin.000071 Replica_IO_Running: Yes Replica_SQL_Running: Yes ...
两台的IO和SQL线程均为YES，说明都正常
2. 查看binlog列表
- db01
mysql> show binary logs; +------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +------------------+-----------+-----------+ | mysql-bin.000054 | 3403136 | No | | mysql-bin.000055 | 4405820 | No | | mysql-bin.000056 | 23387993 | No | | mysql-bin.000057 | 7747401 | No | | mysql-bin.000058 | 20376333 | No | | mysql-bin.000059 | 1421676 | No | | mysql-bin.000060 | 11762442 | No | | mysql-bin.000061 | 106139 | No | | mysql-bin.000062 | 29829686 | No | | mysql-bin.000063 | 275 | No | | mysql-bin.000064 | 44495957 | No | | mysql-bin.000065 | 23984155 | No | | mysql-bin.000066 | 3381900 | No | | mysql-bin.000067 | 79700058 | No | | mysql-bin.000068 | 46420313 | No | | mysql-bin.000069 | 18793760 | No | | mysql-bin.000070 | 3059876 | No | | mysql-bin.000071 | 23207777 | No | | mysql-bin.000072 | 502239 | No | +------------------+-----------+-----------+ 19 rows in set (43.05 sec) mysql>
- db02
mysql> show binary logs; +------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +------------------+-----------+-----------+ | mysql-bin.000055 | 2758206 | No | | mysql-bin.000056 | 332959 | No | | mysql-bin.000057 | 171809 | No | | mysql-bin.000058 | 27972976 | No | | mysql-bin.000059 | 5465998 | No | | mysql-bin.000060 | 2171749 | No | | mysql-bin.000061 | 33699992 | No | | mysql-bin.000062 | 104275 | No | | mysql-bin.000063 | 29770161 | No | | mysql-bin.000064 | 259 | No | | mysql-bin.000065 | 44606908 | No | | mysql-bin.000066 | 23973022 | No | | mysql-bin.000067 | 3362504 | No | | mysql-bin.000068 | 79785449 | No | | mysql-bin.000069 | 46437843 | No | | mysql-bin.000070 | 18810455 | No | | mysql-bin.000071 | 3050696 | No | | mysql-bin.000072 | 23235692 | No | | mysql-bin.000073 | 513397 | No | +------------------+-----------+-----------+ 19 rows in set (11.81 sec) mysql>
3. 查看当前正在使用的binlog
- db01
mysql> show master status\G; *************************** 1. row *************************** File: mysql-bin.000072 Position: 1232726 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 9208096f-4731-11ec-a23e-005056210589:1-23:31-585, 92099aae-4731-11ec-a3da-00505629525b:1-1406317 1 row in set (0.00 sec) ERROR: No query specified mysql>
- db02
mysql> show master status\G; *************************** 1. row *************************** File: mysql-bin.000073 Position: 2065293 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 9208096f-4731-11ec-a23e-005056210589:1-585, 92099aae-4731-11ec-a3da-00505629525b:1-1407638 1 row in set (0.00 sec) ERROR: No query specified mysql>
注意：db01当前使用的是mysql-bin.000072，db02当前使用的是mysql-bin.000073，正在使用的binlog文件是绝对不能手动去删除，不然会引发不可预料的问题。
4. ”暴力“手动直接删除
- 笔者只在db01上操作，db02是一样的操作，笔者就不重复撰写。
注意，之前查看到db01正在使用的binlog文件是mysql-bin.000072，所以，除了当前正在使用的mysql-bin.000072外，其他的可以全部删除，我说的是可以，当然要删除哪些你自己看着办呗！
- 先搜索出要删除的binlog文件，文件比较多时可以用find命令，并排除不需要删除的binlog文件
[root@zbx-db01 mysql_data]# cd /data/mysql_data [root@zbx-db01 mysql_data]# find ./ -type f -name "mysql-bin.*" ! -name "mysql-bin.index" ! -name "mysql-bin.000072" ./mysql-bin.000070 ./mysql-bin.000065 ./mysql-bin.000060 ./mysql-bin.000071 ./mysql-bin.000055 ./mysql-bin.000059 ./mysql-bin.000057 ./mysql-bin.000068 ./mysql-bin.000061 ./mysql-bin.000058 ./mysql-bin.000067 ./mysql-bin.000064 ./mysql-bin.000069 ./mysql-bin.000056 ./mysql-bin.000054 ./mysql-bin.000062 ./mysql-bin.000063 ./mysql-bin.000066 [root@zbx-db01 mysql_data]#
注意：要排除掉db01正在使用的binlog文件mysql-bin.000072，还要排除掉binlog索引文件mysql-bin.index，可别误删了哦！
- 开始删除
find ./ -type f -name "mysql-bin.*" ! -name "mysql-bin.index" ! -name "mysql-bin.000072" | xargs rm -rf
- 删除之后，搜索看看，就剩俩了
[root@zbx-db01 mysql_data]# find ./ -type f -name "mysql-bin.*" ./mysql-bin.index ./mysql-bin.000072
- 接着很重要的一步，手动清理掉mysql-bin.index中已删除的条目，笔者删除后，用cat查看
[root@zbx-db01 mysql_data]# cat mysql-bin.index ./mysql-bin.000072
关于mysql-bin.index的作用，其作用是加快查找binlog文件的速度。
- 接着登录数据库查看binlog信息，发现已删除的还在，但File_size都为0了
mysql> show binary logs; +------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +------------------+-----------+-----------+ | mysql-bin.000054 | 0 | No | | mysql-bin.000055 | 0 | No | | mysql-bin.000056 | 0 | No | | mysql-bin.000057 | 0 | No | | mysql-bin.000058 | 0 | No | | mysql-bin.000059 | 0 | No | | mysql-bin.000060 | 0 | No | | mysql-bin.000061 | 0 | No | | mysql-bin.000062 | 0 | No | | mysql-bin.000063 | 0 | No | | mysql-bin.000064 | 0 | No | | mysql-bin.000065 | 0 | No | | mysql-bin.000066 | 0 | No | | mysql-bin.000067 | 0 | No | | mysql-bin.000068 | 0 | No | | mysql-bin.000069 | 0 | No | | mysql-bin.000070 | 0 | No | | mysql-bin.000071 | 0 | No | | mysql-bin.000072 | 3645040 | No | +------------------+-----------+-----------+ 19 rows in set (0.07 sec)
- 刷新日志，以及再次查看
# 刷新logs mysql> flush logs; Query OK, 0 rows affected (1.62 sec) # 刷新后查看，发现又自动生成了一个新的mysql-bin.000073 mysql> show binary logs; +------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +------------------+-----------+-----------+ | mysql-bin.000072 | 3659564 | No | | mysql-bin.000073 | 1973 | No | +------------------+-----------+-----------+ 2 rows in set (0.00 sec) mysql> # 且当前使用的就是最新的binlog文件， mysql> show master status\G; *************************** 1. row *************************** File: mysql-bin.000073 Position: 108261 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 9208096f-4731-11ec-a23e-005056210589:1-23:31-585, 92099aae-4731-11ec-a3da-00505629525b:1-1410247 1 row in set (0.00 sec) ERROR: No query specified mysql> # 查看binlog索引文件mysql-bin.index [root@zbx-db01 mysql_data]# cat mysql-bin.index ./mysql-bin.000072 ./mysql-bin.000073
flush logs命令的作用就是刷新binlog日志，刷新后会自动生成新的binary log文件，且文件的序号加1。其实，当mysql服务停掉后，再拉起，也会自动生成一个新的binlog日志文件。
写在最后，因笔者每天时间有限，为了保持文章的高质量，今晚就只对“暴力”直接删除binlog文件的方案进行分析，关于另外2个删除办法，我们明天继续谈谈！今晚就此搁笔，感谢大家的耐心观看。
