MySQL BlackHole 存储引擎使用

 BlackHole “黑洞”，高大上的样子，但它 No transaction，no xa，no savepoint，这些都没有阻挡他的应用；show engines 中会显示 blackhole  的comment 为：/dev/null storage engine (anything you write to it disappears)
   它有自己特定的应用场景：
   1、充当dummy master
   当master后面挂载过多的slave，利用 blackhole 来充当一个 "dummy master" 来减轻master的负载（延迟是需要考虑的）；这里需要提一下的是: 对于 master来说“dummy master” 还是一个slave的角色， 由于binlog 设计中是不记录 engine=xxxx 关键字的，采用默认的存储引擎（除非在create 语句中 显式声明 engine=innodb）,所以对于dummy master 来说 只要设置 default_storage_engine=blackhole 就能实现主从 使用不一致的存储引擎；
   2、充当日志服务器
   对于blackhole的slave启用log_slave_updates 这个参数，通过解析相关语句来做审计或者观测服务器负载的情况；需要考虑的问题，如果binlog format 为 row 模式，解析 binlog 查看SQL语句将是一个小问题，mysqlbinlog -vv 这个不单纯显示的SQL ，还有部分“前后镜像”，这里有一个脚本来解析SQL：http://hidba.org/wp-content/uploads/2012/10/parse_binlog.txt ，还是希望有一个同意管理工具来处理，有时间来写一个。。
   3、充当增量备份服务器
   免去拷贝binlog的问题，如果机器数据量多，也需要多个 blackhole的slave实例，这是一个成本问题；其次是 master  binlog  pos 位置和 blackhole 重新产生的pos 是不一致的，在恢复数据的时候需要手动来恢复，不知道有没有工具之类的来做对比； 如果 MySQL 版本达到 5.6+ 那启用GTID 这个选项可以很容易的实现 增量的恢复；
   注意事项：
   master千万不要有blackhole的存储引擎来复制到其他slave；
   造成的影响如下：
   1、如果binlog format 格式为 row或者 mixed 模式，那 delete 和update 是不会记录在binlog里面，并产生warning
   2、对于具有auto_incrment属性的column，由于blackhole 是 no op模式，没有任何记录，所以每次插入的记录，主键ID列都是相同的，造成复制失败；
   3、对于trigger 由于 for each row关键字 ，trigger不会被执行，因为没有一条row