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一樣的引擎名字，這樣的結果是否能夠一樣的提高效率，有待驗證。