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

Val*_*Val 57 mysql blackhole

为什么要保存以后无法检索的内容?重点是什么?

Wil*_*ill 50

它在复制环境中很有用,其中所有SQL语句都在所有节点上运行,但您只希望某些节点实际存储结果.这是文档中给出的用例:http://dev.mysql.com/doc/refman/5.0/en/blackhole-storage-engine.html

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

  • 验证转储文件语法.
  • 通过使用BLACKHOLE在启用和不启用二进制日志记录的情况下比较性能来测量二进制日志记录的开销.
  • BLACKHOLE本质上是一个"无操作"的存储引擎,因此可用于查找与存储引擎本身无关的性能瓶颈.


Mar*_*ery 21

假设您有两台计算机,每台都运行一台MySQL服务器.一台计算机承载主数据库,第二台计算机承载您用作备份的复制从站.

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

但由于复制过滤器仅应用于从属服务器,因此主服务器上执行的所有语句的binlog 仍需要通过网络传输.这里浪费了带宽; 主服务器正在发送binlogs,用于从服务器接收它们时将丢弃的事务.我们能做得更好,并避免不必要的带宽使用吗?

是的,我们可以,而且这就是BLACKHOLE引擎的用武之地.在运行主服务器的同一台计算机上,我们运行第二个虚拟mysqld进程,这个进程负载一个BLACKHOLE数据库.我们将此虚拟进程配置为从主进程的binlog进行复制,具有与真实从属相同的复制选项,并生成自己的binlog.虚拟进程的binlog现在只包含真正的slave需要的语句,除了从binlog中过滤掉不需要的语句之外它没有做任何实际的工作(因为它使用的是BLACKHOLE引擎).最后,我们将真正的slave配置为从虚拟进程的binlog复制,而不是从原始主进程的binlog复制.我们现在已经消除了托管主服务器和从服务器的两台计算机之间不必要的网络流量.

这个设置是由BLACKHOLE文档中的段落和图表描述和说明的(更为简洁):

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

上述场景图

除了过滤之外,文档还密码提示使用启用了binlogging的BLACKHOLE服务器"可以用作转发器...机制".这个用例在文档中很少充实,但可以想象一个这样有意义的场景.例如,假设您有许多从属服务器,所有这些服务器都在本地网络上具有快速本地连接的计算机上,所有这些服务器都需要从远程从属服务器复制大量数据,这些服务器只能通过Internet连接.您不希望将它们全部直接从主盒中复制,因为这样您就可以多次获得相同的数据并使用比您需要多几倍的互联网带宽.但是,假设你不想有从主复制现有的奴隶只是一个和其他人复制过该从属,也许是因为你的奴隶比师傅的运行上更可靠的机器,或者运行一些其他工艺它可能通过吃掉所有CPU或内存来杀死盒子,并且你不想冒中断从属设备上的软件或硬件故障而导致整个从属网络崩溃的风险.你是做什么?

一种可能的折衷方案是在您的从属网络中引入一个额外的盒子作为中介,优化可靠性和性能而不是存储.给它一个小的,可靠的SSD驱动器,除了从mysqld远程主设备复制的进程之外什么也不运行,并让它生成其他从设备可以订阅的binlog.当然,设置这个中间从站以使用BLACKHOLE引擎,这样它就不需要存储空间.

这个和文档中详细描述的中间过滤从站都是边缘情况; 大多数MySQL用户永远不会发现自己会受益于使用这些策略中的任何一种,更不用说有足够的好处来证明做这项工作的合理性.但至少在理论上,BLACKHOLE引擎可用于在复制从属网络中创建一个中间节点作为带宽保护策略,而无需该节点实际将数据存储在磁盘上.