Mysql在互联网领域如此广泛的应用很大程度上是因为它的复制机制，简单实用。用几台PC，很容易提升性能，是中小型网站必备的药方。
首先，我们在什么情况下应该扩充数据库，建网站，建数据库。有一天，网站开始流行，访问量急剧增加，这就意味着从你的服务器上读取网页的连接更多了，IO瓶颈就来了。自然，我们希望添加更多的计算机来分担压力，但是数据应该与源主机上的数据库中的数据一致。这时候就该开始扩展数据库了，复制开始派上用场。
复制的实现机制
第一步，主机必须打开二进制日志Log，里面包含数据库的各种操作记录。从机通过IO线程连接到主控主机，请求日志的内容。该请求还应该包括日志的请求位置，即日志开始的位置。
第二步:master收到请求后，开始通过IO线程向slave返回内容，返回的内容应该包括日志文件的位置，以及下次从哪里开始获取新的日志。
第三步，从机的IO线程将获取的内容记录在本地中继日志文件中，位置内容记录在master-info文件中，以便下次可以快速定位到主机的日志内容。
第四步，slave解析这些日志内容并执行，这样主从数据就可以同步了。
值得注意的是，第三步和第四步同时执行(mysql早期是分开执行的)，两个线程(IO线程和sql线程)异步执行。这样做的好处是减少同步时间，在空之间切换，降低数据丢失的概率。
这是上位机和下位机之间的通信过程。
显然，实际应用中不可能只有一个从，主要有几种聚类方法。
主-从
这是最简单的集群模式，原理同上
主-主
两个主，哪个。它可以防止主服务器的停机时间导致需要重新部署从服务器。这里有个问题，就是两个主意味着双方都要提供读写功能。在实际操作中，应该避免同一个表在主表的两侧提供写功能，这样会导致脏数据。有些表应写在主机1侧，有些表应写在主机2侧。
主-从-从
这个架构的目的也很明确。当普通主从架构的从机越来越多的时候，连接到主机的IO线程就会越来越多，主机还要对外提供写服务，压力太大。这种架构是给主设备解压，把IO转移给从设备，然后从设备给二级从设备提供IO服务。弊端自然是显而易见的，耽误严重。
主人-主人-奴隶-奴隶
这种最复杂，最安全，最稳定，相当于把第二种和第三种结合起来。
上述垂直扩展架构是常用的，主要解决大规模并发读取的问题。至于并发写，需要用mysql数据分段，明天再写。