mysql 备库,高性能MySQL：主库、分发主库以及备库

我们之前提到当备库足够多时，会对主库造成很大的负载。每个备库会在主库上创建一个线程，并执行binlogdump命令。该命令会读取二进制日志文件中的数据并将其发送给备库。每个备库都会重复这样的工作，它们不会共享binlog dump的资源。

如果有很多备库，并且有大的事件时，例如一次很大的L0AD DATA INFILE操作，主库上的负载会显著上升，甚至可能由于备库同时请求同样的事件而耗尽内存并崩溃。另一方面，如果备库请求的数据不在文件系统的缓存中，可能会导致大量的磁盘检索，这同样会影响主库的性能并增加锁的竞争。

因此，如果需要多个备库，一个好办法是从主库移除负载并使用分发主库。分发主库事实上也是一个备库，它的唯-目的就是提取和提供主库的二进制日志。多个备库连接到分发主库，这使原来的主库摆脱了负担。为了避免在分发主库上做实际的查询，可以将它的表修改为blackhole存储引擎。

很难说当备库数据达到多少时需要一个分发主库。按照通用准则，如果主库接近满负载，不应该为其建立10个以上的备库。如果有少量的写操作，或者只复制其中一部分表，主库就可以提供更多的复制。另外，也不一定只使用一个分发主库。如果需要的话，可以使用多个分发主库向大量的各库进行复制，或者使用金字塔状的分发主库。在某些情况下，可以通过设置slave_compressed_protoco来节约一些主库带宽。 这对跨数据中心复制很有好处。

还可以通过分发主库实现其他目的，例如，对二进制日志事件执行过速和重写规则。这比在每个备库上重复进行日志记录、重写和过滤要高效得多。如果在分发主库上使用blackhole表，可以支持更多的备库。虽然会在分发主库执行查询，但其代价非常小，因为blackhole表中没有任何数据。blockhole 表的缺点是其存在Bug,例如在某些情况下会忘记将自增ID写人到二进制日志中。所以要小心使用blackhole表。

一个比较常见的问题是如何确保分发

storage_ engine = blackhole

这只会影响那些没有指定存储引擎的CREATE TALE的语句，如果有一个无法控制的应用，这种拓扑结构可能会非常脆弱。可以通过skip_innodb 选项禁止InoDB,将表退化为MyISAM。但你无法禁止MyISAM成者Memory引擎。

使用分发主库另外一个主要的缺点是无法使用一个备库来代替主库。因为由于分发主库的存在，导致各个备库与原始主库的二进制日志坐标已经不相同。