mysql 复制和容量规划,高性能MySQL：复制和容量规划

写操作通常是复制的瓶颈，并且很难使用复制来扩展写操作。当计划为系统增加复制容量时，需要确保进行了正确的计算，否则很容易犯一些复制相关的错误。

例如，假设工作负载为20%的写以及80%的读。为了计算简单，假设有以下前提:

●读和写查询包含同样的工作量。

●所有的服务器是等同的，每秒能进行1000次查询。

●备库和主库有同样的性能特征。

●可以把所有的读操作转移到备库。

如果当前有一个服务器能支持每秒1000次查询，那么应该增加多少备库才能处理当前两倍的负载，并将所有的读查询分配给备库?

看上去应该增加两个备库井将1 600次读操作平分给它们。但是不要忘记，写人负载同样增加到了400次每秒，并且无法在主备

如果负载再增加一倍呢?将有每秒800次写人，这时候主库还能处理，但备库的写入同样也提升到80%，这样就需要16台备库来处理每秒3200次读查询。井且如果再增加一点负载，主库也会无法承担。

这远远不是线性扩展，查询数量增加4倍，却需要增加17倍的服务器。这说明当为单台主库增加备库时，将很快达到投入远高干回报的地步。这仅仅是基于上面的假设，还忽略了一些事情，例如，单线程的基于语句的复制常常导致备库容量小于主库。真实的复制配置比我们的理论计算还要更差。

为什么复制无法扩展写操作

糟糕的服务容量比例的根本原因是不能像分发读操作那样把写操作等同地分发到更多服务器上。换句话说，复制只能扩展读操作，无法扩展写操作。

你可能想知道到底有没有办法使用复制来增加写人能力。答案是否定的，根本不行。对数据进行分区是唯-可以扩展写人的方法。一些读者可能会想到使用主-主拓扑结构(参阅前面介绍的“主动-主动模式下的主-主复制”)并为两个服务器执行写操作。这种配置比主备结构能支持稍微多一点的写人，因为可以在两台服务器之间共享串行化带来的开销。如果每台服务器上执行50%的写人，那复制的执行量也只有50%需要串行化。理论上讲，这比在一台机器上(主库)对100%的写人并发执行，而在另外一一台机器(备库)上对100%的写人做串行化要更优。

这可能看起来很吸引人，然而这种配置还比不上单台服务器能支持的写人。一个有50%的写人被串行化的服务器性能比一台全部写人都并行化的服务器性能要低。这是这种策略不能扩展写人的原因。它只能在两台服务器间共享串行化写人的缺点。所以“链中最弱的一环”并不是那么弱，它只提供了比主动-被动复制稍微好点的性能，但是增加了很大的风险，通常不能带来任何好处。