1）正常情况下，记录满之后，自动滚动，后缀名+1
2）重启mysql服务之后，自动滚动，不管时候记录满
3）手动滚动，执行flush logs命令，如下执行flush logs之后，重新生成了一个二进制日志文件
4）手动删除二进制日志
可以通过命令purge binary logs to fileName删除指定fileName之前的文件
可以通过命令purge binary logs before '2017-03-10 10:10:00'删除指定时间之前的文件
删除指定日志purge binary logs before date_sub( now( ), interval 7 day);
潇湘大神是purge master logs before date_sub( now( ), interval 7 day),应该是一个效果（binary和master关键词）？
7，二进制日志的绑定（或者排除）的数据库
可以设置某些数据库开启二进制日志，或者某些数据库不开启二进制日志
# binlog_do_db:设置master-slave时使用;
# binlog-ignore-db:设置哪个数据库不记录日志;
MySQL5.7.18中设置了（my.cnf中配置了），但是查询的时候好像没用?
8，二进制日志的缓存以及缓存大小配置
binlog_cache_size的大小，一开始提到的问题，当事物开始的时候，会按照binlog_cache_size系统变量指定的值分配内容空间，如果指定的binlog_cache_size缓存空间不够则会报错并回滚事物
这里显示的记录的单位同样是字节，除以两个1024之后就是以MB为单位的容量了，这里的20971520 /1024/1024就相当于20MB了。
如果有较大的事务性操作，比如在测试的时候，必须要将此缓存设置的相对较大一些，否则语句无法成功执行
max_binlog_cache_size语binlog_cache_size的区别在于前者是实例级别的cache，后者是Session级别的cache，如果并发量很大，就需要考虑将max_binlog_cache_size设置的稍微大一些。
max_binlog_cache_size默认是是4GB，最大值也是4GB，这里为了测试设置的是100MB（104857600/1024.0/1024.0）
max_binlog_cache_size设置的最大内存大小为4GB，如果服务器内容较大，比如128GB或者更大，max_binlog_cache_size默认为最大也无伤大雅，因为要保证并发成功写入。
至于对于Session级别的binlog_cache_size大小，可以根据业务情况自行调整，个人觉得设置的稍微大一点也问题不大，毕竟，有一些定时作业之类的数据提取或者merge之类的操作可能会产生大量的日志。
据说是可以通过查看binlog_cache_disk_use 与 binlog_cache_use来判断binlog_cache_size是否需要调整。
但是在MySQL5.7.18中并没有发现这个参数
9，二进制日志其他参数
max_binlog_stmt_cache_size针对非事务语句，非事务性的参数暂不关心它了
记得某次看到过某大师说过，innodb引擎优势不仅仅在事务性的支持上，与非事物引起的myisam引擎相比，读取性能上差距越来越小，MySQL因此将innodb设置为默认引擎。
放弃myisam，投奔innodb是正道。
binlog_checksum 用作复制的主从校检。暂时没有研究过这个参数，暂不论
总结：
MySQL二进制日志不仅仅作用于功能性（master-slave复制）的，还作用于安全性（二进制日志）以及开启了二进制日志情况下的事务性操作，因此对于生产环境，可以认为是一个必不可少的配置。
同时，其各种参数又会影响到某些操作，因此二进制日志的参数要格外的重视，确保数据库在使用时在功能性和可用性上得到保证。
