标签：blackhole
BlackHole ：黑洞引擎，写入的任何数据都会消失，用于记录binlog做复制的中继存储！
是否支持BLACKHOLE引擎，通过查看SHOW ENGINES进行查看。
BlackHole的用途:
用于binlog的备份
线上MySQL的binlog一般会保留3-5天，但是对比较重要的业务，binlog可能需要保留一个月甚至半年。线上服务器可没有这么大的空间，最多保留10天就会被purge掉。此时blackhole就有了用武之地。blackhole从库+xtrabackup的定期热备+binlogflashback，可以让你的数据库恢复到任意时刻。
充当binlog API，为其他程序提供数据源
可作为其他程序提供数据源的接口，如在BLACKHOLE获取BINLOG分析把对应的数据插入到redis中。这种情况下blackhole从库充当了天然的binlog API。
跨IDC部署场景下，节省带宽
如果一个主库拖着20个从库，主库可能不堪重负，此时可以考虑给主库增加一个blackhole从库作为中继，虽然这种方案有诸多不靠谱的地方，但是如果这个主库在北京，20个从库在广州，这种方案就有意义了：在广州增加一个blackhole，让blackhole下挂20个从库，此时就可节省大量北京到广州的带宽。
。。。。。。
应用场景：
主服务器的操作写入二进制日志,伪mysqld进程作为从服务器，在伪mysqld进程上配置replicate-do和replicate-ignore规则，并且写一个新的，被过滤的二进制日志。这个已过滤日志被提供给其他真正的从服务器。因为伪进程不存储任何数据，只消耗很小的额外的mysqld进程资源。这个类型的建立可以用额外复制从服务器来重复。
当然如果配置一主多从的话，多个从服务器会在主服务器上分别开启自己相对应的线程，执行binlog dump命令而且多个此类进程并不是共享的。为了避免因多个从服务器同时请求同样的事件而导致主机资源耗尽，可以单独建立一个伪的从服务器或者叫分发服务器：
测试环境：
SERVER | IP | ROLE | Data_format |
MASTER | 192.168.15.2 | 主库 | RBR |
BLACKHOLE | 192.168.15.13 | 分发服务器 | RBR |
SLAVE | 192.168.15.104 | 分发服务器的从库 | RBR |
搭建过程：
1、在master 添加一个帐号作为BLACKHOLE同步BINLOG使用
2、在BLACKHOLET添加一个帐号作为SLAVE同步BINLOG使用
3、可以指定需要同步的库表或者忽略某些表（replicate-do和replicate-ignore规则）
4、新环境搭建主从过程：
1、实例启动后对master执行show masterstatus 获取到的BINLOG FIEL 和POS作为BLACKHOLE的连接使用
2、实例启动后对BLACKHOLE执行show masterstatus 获取到的BINLOG FIEL 和POS作为SLAVE的连接使用
3、在主库添加DDL的时候，不要再次指定ENGINE，根据实例配置走即可，若再次指定引擎，到BLACKHOLE，同步的BINLOG的中的DDL语句没法使用BLACKHOLE引擎，不符合黑洞引擎，写入的任何数据都会消失这一说法，虽然也能同步，感觉为线性级联方式同步
注意：在BLACKHOLE需要开启log_slave_updates和BINLOG服务器才能作为SLAVE的同步数据源
5、对于旧环境添加BLACKHOLE服务器：
1、如果在DDL指定ENGINE话，到BLACKHOLE服务器存储的表和主库一致，不符合黑洞引擎，写入的任何数据都会消失这一说法
2、在导入旧数据的时候，需要修改导入数据表的引擎为BLACKHOLE
3、在BLACKHOLE连接着SLAVE时候，需要把SLAVE引擎改为和主库一致
4、备份的数据不需要DDL语句，只要数据，在主库导入即可，后期写入的数据，即可通过BLACKHOLE同步快速同步到不同的SLAVE上
最终结果图：
主库上的DDL：
BLACKHOLE的DDL:
SLAVE上的DDL
实验现象：
在测试1000W数据写入的时候，BLACKHOLE同步MASTER的速度很快，
SLAVE的IO线程同步BLACKHOLE的BINLOG日志速度也快，但SLAVE的SQL_THREAD线程的速度跟不上（MySQL版本为5.6，或用5.7的多个线程可提高效率）.数据获取多次展示：
master binlog event File:mysql-bin.000006
Position:777525175
blackhole master event File:mysql-bin.000007
Position:129152031
BLACKHOLE SYNE:
Master_Log_File:mysql-bin.000006
Read_Master_Log_Pos: 776113906
Relay_Log_File:relay-log.000010
Relay_Log_Pos: 458099520
Exec_Master_Log_Pos: 458099357
SLAVE SYNE:
Master_Log_File:mysql-bin.000007
Read_Master_Log_Pos: 129152031
Relay_Log_File:relay-log.000017
Relay_Log_Pos: 129007567
Exec_Master_Log_Pos: 129007404
master binlog event File:mysql-bin.000006
Position:844042095
blackhole master event File:mysql-bin.000007
Position:152147724
BLACKHOLE SYNE:
Master_Log_File:mysql-bin.000006
Read_Master_Log_Pos: 843124455
Relay_Log_File:relay-log.000010
Relay_Log_Pos: 481091238
Exec_Master_Log_Pos: 481091075
SLAVE SYNE:
Master_Log_File:mysql-bin.000007
Read_Master_Log_Pos: 152147724
Relay_Log_File:relay-log.000017
Relay_Log_Pos: 152147887
Exec_Master_Log_Pos: 152147724
master binlog event File:mysql-bin.000006
Position:936876579
blackhole master event File:mysql-bin.000007
Position:199585380
BLACKHOLE SYNE:
Master_Log_File:mysql-bin.000006
Read_Master_Log_Pos: 936441390
Relay_Log_File:relay-log.000010
Relay_Log_Pos: 528520694
Exec_Master_Log_Pos: 528520531
SLAVE SYNE:
Master_Log_File: mysql-bin.000007
Read_Master_Log_Pos: 199585380
Relay_Log_File:relay-log.000017
Relay_Log_Pos: 199585543
Exec_Master_Log_Pos: 199585380
master binlog event File:mysql-bin.000007
Position:131443338
blackhole master event File:mysql-bin.000007
Position:444149637
BLACKHOLE SYNE:
Master_Log_File:mysql-bin.000007
Read_Master_Log_Pos: 131044087
Relay_Log_File:relay-log.000010
Relay_Log_Pos: 773042676
Exec_Master_Log_Pos: 773042513
SLAVE SYNE:
Master_Log_File:mysql-bin.000007
Read_Master_Log_Pos: 444020772
Relay_Log_File: relay-log.000017
Relay_Log_Pos: 384708103
Exec_Master_Log_Pos: 384707940
master binlog event File:mysql-bin.000007
Position:286312080
blackhole master event File:mysql-bin.000007
Position:679313139
BLACKHOLE SYNE:
Master_Log_File:mysql-bin.000007
Read_Master_Log_Pos: 286167931
Relay_Log_File:relay-log.000010
Relay_Log_Pos: 1008165528
Exec_Master_Log_Pos: 1008165365
SLAVE SYNE:
Master_Log_File:mysql-bin.000007
Read_Master_Log_Pos: 679191406
Relay_Log_File:relay-log.000017
Relay_Log_Pos: 537578842
Exec_Master_Log_Pos: 537578679
master binlog event File:mysql-bin.000008
Position:249583172
blackhole master event File:mysql-bin.000008
Position:469748616
BLACKHOLE SYNE:
Master_Log_File:mysql-bin.000008
Read_Master_Log_Pos: 249368601
Relay_Log_File:relay-log.000013
Relay_Log_Pos: 798058721
Exec_Master_Log_Pos: 798058558
SLAVE SYNE:
Master_Log_File:mysql-bin.000008
Read_Master_Log_Pos: 469654916
Relay_Log_File:relay-log.000020
Relay_Log_Pos: 333076264
Exec_Master_Log_Pos: 333076101
由此看出，在1000W 写入的时候，MASTER与BLACKHOLE的IO_THREAD延迟不是很大，取决于BLACKHOLE的SQL_THREAD。需要注意的是，在主库的添加DDL不能指定引擎名字，让数据库实例自行为DDL添加引擎即可，否则在BLACKHOLE中也会和M一样的引擎名字，这样的结果是否能够一样的提高效率，有待验证。
本文出自 “DBSpace” 博客，请务必保留此出处http://dbspace.blog.51cto.com/6873717/1895182
标签：blackhole
原文地址：http://dbspace.blog.51cto.com/6873717/1895182
