MySQL BlackHole引擎

摘要：作为日志收集器其不保存实际数据，只记录的特性，使得该引擎可用于日志收集，便于数据库分析。忽略，当建表语句带有时，将使用默认的引擎。需要提醒的是，当采用这种架构时，数据同步多了中间一层，需要进一步考虑延迟问题。

像MyISAM、InnoDB，BlackHole是另一种MySQL引擎，从字面意思来看，
其表现就像一个黑洞，只进不出，进来就消失。换句话说，任何往其中写的数据都将丢失，有点像Linux的/dev/null
比如一个表test的引擎是BlackHole，任何对这个表的insert都将丢失，
对它的select永远返回空集，对应的数据目录下只有一个test.frm文件，且没有其他文件与之关联。

一个并不保存任何数据的引擎，到底有什么意义？
关键在于，虽然其不保存数据，但对数据库的操作仍旧记录在binlog日志中。
这就带来一个好处，可以将其作为主从复制的中介，将原来从主库中同步的操作变为从作为中介的BlackHole引擎数据库中同步。

众所周知，当从库比较多的时候，所有从库都从主库load数据将加重主库的负担。但如果是从BlackHole的伪主库中同步就可以减轻主库的负担。原有主从架构大概就像下面这样：

现在，BlackHole伪主库作为中介，变成这样：

特别是，可以在伪主库中配置replicate-do和replicate-ignore规则，过滤不需要同步的表。

其不保存实际数据，只记录binlog的特性，使得该引擎可用于binlog日志收集，便于数据库分析。
相关知识：binlog日志的format有三种：row,statement,mixed。
row的方式记录每一行被改变的记录，也就说，update将记录所有符合条件被修改的行，alter table更惨，相当于重建整个表，记录所有行的改变。所以这种格式下日志容易过大；
statement的方式只记录改变数据的SQL，没有row方式的问题，但其会记录该SQL执行的上下文信息，有个不好的地方是，该上下文信息在另一端重现的时候，容易因为较复杂的信息负责出错。
mixed的方式综合row和statement的方式。

在伪库中，需要如下配置：
配置默认类型为BlackHole，可以用
default_table_type = BLACKHOLE
或是
default-storage-engine = BLACKHOLE
打开binlog：log-bin = ms-mysql-bin
特别要配置：log-slave-update = 1，只有这样，主库中的操作才会同步到BlackHole的binlog中，否则，只有直接针对BlackHole的操作才会记录到binlog。
忽略InnoDB：skip-innodb，当建表语句带有engine=innodb时，将使用默认的BlackHole引擎。
需要提醒的是，当采用这种架构时，数据同步多了中间一层，需要进一步考虑延迟问题。