这几天看了不少google针对于mysql开发的google-mysql-tools，找到一个很有意思的patch：mirroredbinlogs。 这个patch通过修改mysql replication中slave io线程的实现，让该线程在写入relay log的同时，再mirror了一份与master端完全一模一样binlog。这里所说
这几天看了不少google针对于mysql开发的google-mysql-tools，找到一个很有意思的patch：mirroredbinlogs。
这个patch通过修改mysql replication中slave io线程的实现，让该线程在写入relay log的同时，再mirror了一份与master端完全一模一样binlog。这里所说的一模一样不仅仅是binlog的内容完全一样，同时还包括binlog的文件名。也就是说，该线程在slave端完全copy了一份master的binlog日志。
在该 patch 的描述中，该 patch 产生的初衷是为了解决slave与master之前的顺利切换，并保证切换之后其他slave仍然能够正常从新的master继续进行复制。
作者设想了如下一个场景：
在 hierarchical replication（级联复制）环境中，第一层是有一台 master ，第二层是两台 slaves ，这两台slave主要作用是作为第三层更多 slave 的 master 。也就是，第二层的两台 slave 的角色在整个集群环境中是一个复制代理。如果我们使用的是普通的mysql，那么中间代理层的两台slave之间的binlog日志可能会有较大差异，因为两台slave自身也会有产生binlog的event。而通过使用该patch之后，通过 slave io 线程将第一层中 master 的binlog完全一模一样的copy到第二层的 slave 上面，而使这一层的binlog完全一致。这样，当第二层的两台复制代理机器中的一台crash之后，可以很容易的将第三层中以 前面 crash 的 slave 作为 master 的所有 slave 可以很容易的切换 master 到另外一台 代理 slave 上面。
只不过，开发者已经停止了该patch的更新，并将该patch整合到了一个新的叫 globaltransactionids（mysql hierarchical replication & global group ids）的patch中，只不过该patch还正在开发中。从 google 在 globaltransactionids 的介绍中可以看到比其他 patch 更为详细的一些说明，不知道是否算是对该 patch 比较重视的一个表现呢？ 希望不是我的一厢情愿吧。
自己目前还没有详细测试过 mirroredbinlogs 这个 patch，也不知道是否奏效，不过我想 google 应该不会在技术这种事情上拿自己的名声和我们开这种玩笑吧，哈哈。如果有哪位朋友已经做过相关的测试的话，就 share 一下效果吧…
原文地址：mysql patch – mirroredbinlogs (from google), 感谢原作者分享。