这几天看了不少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), 感谢原作者分享。
