MySQL手册版本 5.0.20-MySQL同步(五) （3）

   来源：MySQL手册版本 5.0.20    作者：译者：叶金荣

问：MySQL同步何时且有多少能提高系统性能？

答：MySQL同步对于频繁读但不频繁写的系统很有好处。理论上来讲，使用单一master/多slave的配置，就可以通过这个方法来衡量系统：增加更多的slave直到用完所有的网络带宽或者master的更新操作增长到了不能再处理的点了。

想要知道增加多少个slave之后得到的性能才能平稳，以及能提高多少性能，就需要知道查询模式，并且根据经验对典型的master和slave做读(每秒读或 max_reads)和写(max_write)基准测试得到它们之间的关系。下例展示了一个理想系统取得的性能的简单计算方法。

设定系统负载由10%写和90%读组成，我们已经通过基准测试确定 max_reads 是1200 - 2 * max_writes。换句话说，系统可以达到每秒做没有写的1200次读操作，写操作平均是读操作的2倍慢，它们之间的关系是线性的。让我们假设master和每个slave都有同样的容量，有一个master和N个slave。每个服务器(master或slave)：

reads = 1200 - 2 * writes

reads = 9 * writes / (N + 1) (读是分开的，但是所有写是在所有的服务器上的)

9 * writes / (N + 1) + 2 * writes = 1200

writes = 1200 / (2 + 9/(N+1))

最后的等式说明了N个slave的最大写数量，给它每分钟的最高读频率1200和1次写9次读的机率。

分析结论比率如下：

如果 N = 0(意味着没有同步)，系统大致可以处理每秒 1200/11 = 109 次写。

如果 N = 1，增加到每秒 184 次写。

如果 N = 8，增加到每秒 400 次写。

如果 N = 17，增加到每秒 480 次写。

最终，随着N接近无穷大(我们的预算为负无穷大)，则可以达到几乎每秒 600 次写，大约提高系统吞吐量 5.5 倍。尽管如此，当有8台服务器时，已经提高了4倍了。

注意，上面的计算是假设了网络带宽无穷大，并且忽略了一些系统中比较大的因素。在很多情况下，当系统增加 N 个同步slave之后，是无法精确计算出上述预计结果的。不过，先看看下列问题将有助于你知道是否有和有多少系统性能上的改善：

系统读/写得比率是多少？

减少读操作后一个服务器能增加处理多少写操作？

你的网络带宽足够给多少slave使用？

问：如何利用同步提供冗余/高可用性？

答：使用当前已经可用的特性，可以配置一个master和一个(或多个)slave，并且写一个脚本监控master是否运行着。然后通知应用程序和slave在发现错误时修改master。一些建议如下：

使用 CHANGE MASTER TO 语句告诉slave修改master。

一个让应用程序定位master所在主机的办法就是给master使用动态DNS。例如bind就可以用 `nsupdate` 来动态更新DNS。

使用 --log-bin 选项，不使用

--log-slave-updates 选项来启动slave。这样就能让slave运行 STOP SLAVE; RESET MASTER 语句后随时准备变成master，并且在其他slave上运行

CHANGE MASTER TO。例如，有以下配置方案：

WC
        \
         v
 WC----> M
       / | \
      /  |  \
     v   v   v
    S1   S2  S3

M 表示masetr，S 表示slave，WC表示提交读写操作的客户端；只提交读操作的客户端没有表示出来，因为它们无需切换。S1，S2，S3都是使用

--log-bin 选项，不用 --log-slave-updates 选项运行的slave。由于除非指定 --log-slave-updates 参数，否则从master读到的更新操作都不会记录到二进制日志中，因此每个slave上的二进制日志都是空的。如果因为某些原因 M 不能用了，可以指定一个slave作为master。例如，如果指定S1，则所有的WC都要重定向到S1上，S2和S3都需要从S1上同步。

确定所有的slave都已经处理完各自的中继日志了。在每个slave上，提交 STOP SLAVE IO_THREAD 语句，然后检查 SHOW PROCESSLIST 的结果直到看到 Has read all relay log 了。当所有的slave都这样子之后，就可以按照新的方案设置了。在slave S1上提交

STOP SLAVE 和 RESET MASTER 语句将其提升为master。

在其他slave S2和S3上，提交 STOP SLAVE 和 CHANGE MASTER

TO MASTER_HOST='S1' ( 'S1' 代表S1的真实主机名) 语句修改master。把S2，S3如何连接到S1的参数(用户，密码，端口等)都附加到 CHANGE MASTER 后面。在

CHANGE MASTER 中无需指定S1的二进制日志文件名和偏移位置：因为 CHANGE MASTER 默认就是第一个二进制日志和偏移位置4。最后，在S2和S3上提交 START SLAVE 语句。

然后让所有的WC都把他们的语句重定向到S1上。从这个时候开始，从所有的WC发送到S1上的更新语句都会写到S1的二进制日志中，它们包含了从M死掉之后发送到S1的全部更新语句。

配置结果如下：

WC
      /
      |
 WC   |  M(unavailable)
  \   |
   \  |
    v v
     S1<--S2  S3
      ^       |
      +-------+

当M又起来了之后，只需在M上提交和在S2和S3上的一样的 CHANGE MASTER 语句，将它变成一个slave并且读取自从它死掉之后的全部WC提交的更新操作。想要把M重新变成master(例如因为它的性能更好)，就执行类似上面的操作，把S1当作失效了，把M提升为新的master。在这个步骤中，别忘了在把S2和S3修改成为M的slave之前在M上运行 RESET MASTER 语句。否则的话，它们会从M开始失效的那个时刻开始读取WC提交的更新操作日志。

现在我们就运行着一个完整的自动选择master的MySQL同步系统，不过在它准备好之前，需要创建自己的监控工具。