MySQL的BLACKHOLE引擎的目的是什么？

你为什么要保存一些以后不能检索的东西？重点是什么？

在所有节点上运行所有SQL语句的复制环境中，这是非常有用的，但是您只需要一些节点实际存储结果。这是在文档中给出的用例： http : //dev.mysql.com/doc/refman/5.0/en/blackhole-storage-engine.html

文档中给出的其他用途包括：

validation转储文件的语法。

通过比较使用BLACKHOLE和启用二进制日志logging的性能来测量二进制日志logging的开销。

BLACKHOLE本质上是一个“无操作”存储引擎，所以它可以用来查找与存储引擎本身无关的性能瓶颈。

假设你有两台计算机，每台运行一台MySQL服务器。一台计算机承载主数据库，另一台计算机承载您用作备份的复制从服务器。

另外，假设您的主服务器包含一些您不想备份的数据库或表。也许他们是高stream量的caching表，如果你失去了内容，这并不重要。因此，为了节省磁盘空间并避免不必要地使用CPU，内存和磁盘IO，可以使用复制选项将从属configuration为忽略影响不需要备份的表的语句。

但是由于复制filter只能应用到从服务器上 ，所以在主服务器上执行的所有语句的二进制日志仍然需要通过networking传输。这里浪费了带宽; 主服务器正在发送binlogs，以便在从服务器收到它们后立即丢弃这些事务。我们可以做的更好，避免不必要的带宽使用？

是的，我们可以，那就是BLACKHOLE引擎进来的地方。在主服务器运行的同一台计算机上，我们运行第二个虚拟mysqld进程，这个进程拥有一个BLACKHOLE数据库。我们将这个虚拟进程configuration为从主进程的二进制日志复制，具有与真实从服务器相同的复制选项，并生成自己的二进制日志。虚拟进程的二进制日志现在只包含真实从机所需的语句，除了从二进制日志中滤除不需要的语句（因为它使用的是BLACKHOLE引擎）以外，还没有做任何实际的工作。最后，我们configuration真正的从服务器从虚拟进程的二进制日志复制，而不是从原始主进程的二进制日志复制。现在我们已经消除了两台主机和从属服务器之间的不必要的networkingstream量。

这个设置是由BLACKHOLE文档中的这个段落和图表所描述和说明的（更加简洁）：

假设您的应用程序需要从端过滤规则，但是将所有二进制日志数据传输到从服务器会导致stream量过大。在这种情况下，可以在主控主机上设置一个默认存储引擎为BLACKHOLE的“虚拟”从属进程，如下所示：

除了过滤之外，文档还隐含地暗示，使用启用了binlogging的BLACKHOLE服务器“可以用作中继器…机制” 。这个用例在文档中的performance较less，但是可以想象这种情况是有意义的。例如，假设你有很多的从属服务器，所有的本地networking上的计算机都有快速的本地连接，所有这些服务器都需要从一个只能通过互联网连接的远程从站复制大量的数据。你不想让他们直接从主框中复制，因为那样你会得到相同的数据几次，并使用多倍的互联网带宽比你必须。但是，假设你也不希望只有一个现有的从站从主站复制，而另一些从站复制从站，也许是因为你的从站运行在比主站less得多的可靠机器上，或者正在运行一些其他进程这可能会通过吃掉所有的CPU或内存来杀死这个盒子，并且你不想冒中间从设备上的软件或硬件故障，从而使整个从设备networking失效。你是做什么？

一个可能的折衷办法是在你的从属networking中引入一个额外的盒子作为中介，为可靠性和性能而不是存储进行优化。给它一个小的，可靠的SSD驱动器，除了从远程主服务器复制的mysqld进程外，什么也不运行，并让它产生其他从服务器可以订阅的binlog。而且，当然，将这个中间slave设置为使用BLACKHOLE引擎，这样就不需要存储空间。

文档中详细描述的这个和中间过滤从机都是边缘情况; 大多数MySQL用户永远不会发现自己可以从使用这两种策略中获益，更不用说有足够的好处来certificate这些工作的实际设置。但至less在理论上，BLACKHOLE引擎可以用来在复制从属networking中创build一个中间节点作为带宽保存策略，而不需要该节点实际上将数据存储在磁盘上。