在我的上一篇游记中多次提到一个关键的信息图书馆——Binary Log。很多读者都给我来信询问它的详细介绍。希望通过讲述我认识的binary log，满足大家的好奇心。
我曾经提到过，在准备好迁往slave从库以后，首先需要到master的binary log中进行登记，但是并不是任何人都有资格留下记录的。Binary Log就像是一个档案库，master希望把数据库上的所有改变都存档下来，从而能让slave执行同样的更新。了解到这个目的以后，准入资格就很明确了：Binary Log中只包含可能改变数据库的语句，之所以加上了“可能”两个字，是因为有一些还没有但是可能改变数据库的语句也会被记录下来，比方说我的一个兄弟就获得了准入资格：DROP TABLE IF EXISTS。
进入Binary Log档案馆的通道只有一个，这就意味着我们只能串行地进行登记。但是我和我的兄弟姐妹们并不是排队去往master，我们有可能同时到达。这里有一个细节可要注意了：Binary Log按照master上的提交顺序记录事务，也就意味着，虽然我们交错着到达master，但是在Binary Log中登记的顺序由我们执行完毕的时间决定，或者说由事务的提交时间决定。
说了这么多，你一定对Binary Log的组成感到十分的好奇了吧？别着急，听我慢慢来解释。上次提到过Binary Log并不是一个单独的文件，它由一组记录我们信息的二进制日志事件（binlog事件）和一个索引文件（binlog index）组成。Binary Index的存在主要是为了跟踪master使用的所有binlog文件，master需要依靠它来创建新的binlog文件。我有几个朋友，他们的主要任务是改变binlog文件，结果binlog-index也跟着受到了影响，所以我们总是戏谑他们是气场强大的三剑客，他们是：purge binary logs/ reset master/ flush logs。
每一个binlog文件都有规范的格式，它们都是以格式描述事件（Format_description事件）开头，以日志轮换事件（Rotate事件）结尾。如果master服务器关闭或者重新启动就会创建一个新的binlog文件，哦对了，还有三剑客驾到的时候也会。除了Format_description事件和Rotate事件以外，binlog就被分成了一个一个的组（group）。插一个题外话，master提供不同的存储引擎，在事务存储引擎（transactional storage engine）中，一个group大致对应一个事务，你可以理解为我们组团行动。对于非事务存储引擎，或者不属于事务的语句，比方说CREATE/ALTER这种数据定义语句（DDL），每个语句本身就是一个组，这种可以看做是自由行或者独行侠。
刚刚提到了一个很重要的名词——“事件（EVENT）”。MySQL中用Event来描述Binlog中记录的数据操作，也就是说我们每个人都有自己对应的event。5.0版本的MySQL把我们分成了18类，最新的版本又扩展到了27种。我的旅行是从5.0版本的MySQL出发，那我就作为一个知情人士来做一个内幕揭秘吧。
教你一个简单的办法，虽然官方说event有18类，但是我私下觉得其实也就四大类了：第一类是跟binlog格式或是服务器有关的，他们都比较单纯，比方说Format_Description_Event / Rotate_Event / Xid_Event等都属于这一类；第二类是与文件有关的：Load_Event/ Execute_Load_Query_Event之类的；第三类就是我所在的Query_Event了，我们家族的90%几乎都可以归于Query Event，比方说Insert、Update、Delete；第四类是一群比较让人头疼的糊涂蛋，他们都涉及到上下文事件。所以master对他们是严加管理，通常需要记录好几条信息，让他们把话讲全了才允许通过。他们是Intvar_Event、User_Var_Event和Rand_Event，碰到他们的时候一定要小心对待，切记切记要让他们把隐式信息显示化，也就是说要让他们把当时所处的环境描述清楚。有几个系统变量或许在某些时候能够帮上你的忙：对应Intvar_Event的是@@insert_id、@@last_insert_id；对应User_Var_Event的是用户变量，对应Rand_Event的是记录随机数种子的系统变量@@rand_seed1和@@rand_seed2。
除了上面说到的这些内幕以外，Binary Log还有过滤功能和针对触发器、存储程序的处理方式。鉴于这次的旅程还没有涉及到它们，我也不便多说了。如果你实在感兴趣，我再去申请一次专门的出差来进行调查。那么，这次的故事到此就结束了。任何问题欢迎回复本文。
相关文章
转载请注明：爱开源 » MYSQL的主从复制之旅（2） 关于Binary Log的故事