之前我们搭建blackhole从库，都是先把线上主库或者备库的表结构dump出来，然后把主库的权限库、监控库等整个拷贝过来，再change
来自业务的驱动
前一段时间，微博的双向关注业务拆分，数据库实例增多了几倍，对应的，我们要为这些实例搭建很多blackhole从库，供后面的binlog分析程序分析binlog并最终导入到redis中。整个过程比较枯燥乏味，尤其blackhole从库的搭建，花费了我们较多的精力。所以我有了写个工具的想法。
按部就班的做法之前我们搭建blackhole从库，都是先把线上主库或者备库的表结构dump出来，然后把主库的权限库、监控库等整个拷贝过来，再change master。这种方法在采用语句级格式复制的情况下，基本可以很好的工作。但是当换成行格式复制后，blackhole从库经常卡库。追查了一下原因，发现问题出现在拷贝权限库、监控库[都是MyISAM表]的过程中。如果拷贝过程中不加锁，拷贝完毕后再在主库通过show master status记录下binlog pos点，并以此作为change master的pos点，这种方法可能存在隐患，并最终导致从库出现卡库。
在了解需求和之前方法的缺点后，我发现要非常严谨的给正在运行的主库搭建一个blackhole从库并非易事。经过和同事的一番讨论，参考了下percona xtrabackup热备数据库的方法，于是实现了这个工具。代码有兴趣的可以直接看，文章后面也有比较详细的说明。欢迎拍砖。
MySQL管理之使用XtraBackup进行热备
MySQL开源备份工具Xtrabackup备份部署
MySQL Xtrabackup备份和恢复
用XtraBackup实现MySQL的主从复制快速部署【主不锁表】
安装和使用 Percona 推出的 Xtrabackup 备份 MySQL
源代码下载见 用法说明这个工具需要用户输入两个参数：一个主库的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应该绰绰有余。
用blackhole来测试开启binlog与否对服务器IO的冲击。MySQL官方数据说，开启binlog会使IO性能降低3-5%，这个数据是否有点“保守”？
本文永久更新链接地址：
