前一段时间，微博的双向关注业务拆分，数据库实例增多了几倍，对应的，我们要为这些实例搭建很多blackhole从库，供后面的binlog分析程序分析binlog并最终导入到redis中。整个过程比较枯燥乏味，尤其blackhole从库的搭建，花费了我们较多的精力。所以我有了写个工具的想法。
之前我们搭建blackhole从库，都是先把线上主库或者备库的表结构dump出来，然后把主库的权限库、监控库等整个拷贝过来，再change master。这种方法在采用语句级格式复制的情况下，基本可以很好的工作。但是当换成行格式复制后，blackhole从库经常卡库。追查了一下原因，发现问题出现在拷贝权限库、监控库[都是MyISAM表]的过程中。如果拷贝过程中不加锁，拷贝完毕后再在主库通过show master status记录下binlog pos点，并以此作为change master的pos点，这种方法可能存在隐患，并最终导致从库出现卡库。
在了解需求和之前方法的缺点后，我发现要非常严谨的给正在运行的主库搭建一个blackhole从库并非易事。经过和同事的一番讨论，参考了下percona xtrabackup热备数据库的方法，于是实现了这个工具。代码有兴趣的可以直接看，文章后面也有比较详细的说明。欢迎拍砖。
这个工具需要用户输入两个参数：一个主库的ip地址，一个是主库的数据库端口，这两个参数唯一的确定一个实例。
用法说明
Usage: example: blackhole_slave.py -f 10.66.10.10 -P 3307
Options:
? --version? ? ? ? ? ? show program's version number and exit
? -h, --help? ? ? ? ? ? show this help message and exit
? -f IP, --master-ip=IP
? ? ? ? ? ? ? ? ? ? ? ? master ip address here
? -P PORT, --master-port=PORT
? ? ? ? ? ? ? ? ? ? ? ? master port here
线上MySQL的binlog一般会保留3-5天，但是对比较重要的业务，binlog可能需要保留一个月甚至半年。线上服务器可没有这么大的空间，最多保留10天就会被purge掉。此时blackhole就有了用武之地。blackhole从库+xtrabackup的定期热备+ @plinux的binlog flashback，可以让你的数据库恢复到任意时刻。
我们线上有很多业务，挂在blackhole从库的后面。我们自己开发的binlog分析程序会适时分析binlog，然后把对应的数据插入到redis中。这种情况下blackhole从库充当了天然的binlog API。
如果一个主库拖着20个从库，主库可能不堪重负，此时可以考虑给主库增加一个blackhole从库作为中继，虽然这种方案有诸多不靠谱的地方，但是如果这个主库在北京，20个从库在广州，这种方案就有意义了：在广州增加一个blackhole，让blackhole下挂20个从库，此时就可节省大量北京到广州的带宽。省下的钱加强下blackhole的HA应该绰绰有余。