复制解决的问题是让一台服务器的数据与其他的服务器保持同步。一台主库的数据可以同步到多台备库上去，备库本身也可以被配置成另外一台服务器的主库。
从集中到分布，最基本的一个需求不是数据存储的瓶颈，而是在于计算的瓶颈，即SQL查询的瓶颈，我们知道，正常情况下，Insert SQL就是几十个毫秒的时间内写入完成，而系统中的大多数Select SQL则要几秒到几分钟才能有结果，很多复杂的SQL，其消耗服务器CPU的能力超强，不亚于死循环的威力。我们应该尽量避免没有主从复制机制的单节点数据库。
复制的方案
一主多备库
一个写节点Master后面跟着多个读节点，读节点的数量取决于系统的压力，通常是1-3个读节点的配置
，如下所示
双主库
环形主库
树形库
复制方式
- 基于行的复制(RBR)
- 基于语句的复制(SBR)
- 混合模式复制(MBR)
基于SQL语句的方式最古老的方式，也是目前默认的复制方式，后来的两种是MySQL 5以后才出现的复制方式。
基于行的复制(RBR)的优点：
- 任何情况都可以被复制，这对复制来说是最安全可靠的
- 和其他大多数数据库系统的复制技术一样
- 多数情况下，从服务器上的表如果有主键的话，复制就会快了很多
基于行的复制(RBR)的缺点：
-binlog 大了很多
- 复杂的回滚时 binlog 中会包含大量的数据
- 主服务器上执行 UPDATE 语句时，所有发生变化的记录都会写到 binlog 中，而 SBR 只会写一次，这会导致频繁发生
- binlog 的并发写问题
- 无法从 binlog 中看到都复制了写什么语句
基于语句的复制(SBR)的优点：
- 历史悠久，技术成熟
- binlog文件较小
- binlog中包含了所有数据库更改信息，可以据此来审核数据库的安全等情况
- binlog可以用于实时的还原，而不仅仅用于复制
- 主从版本可以不一样，从服务器版本可以比主服务器版本高
SBR 的缺点：
- 不是所有的UPDATE语句都能被复制，尤其是包含不确定操作的时候。
- 复制需要进行全表扫描(WHERE 语句中没有使用到索引)的 UPDATE 时，需要比 RBR 请求更多的行级锁
- 对于一些复杂的语句，在从服务器上的耗资源情况会更严重，而 RBR 模式下，只会对那个发生变化的记录产生影响
- 数据表必须几乎和主服务器保持一致才行，否则可能会导致复制出错
- 执行复杂语句如果出错的话，会消耗更多资源
选择哪种方式复制，会影响到复制的效率以及服务器的损耗，甚以及数据一致性性问题，目前其实没有很好的客观手手段去评估一个系统更适合哪种方式的复制
主从复制的原理
第一步是在主库上记录二进制日志（稍后介绍如何设置）。在每次准备提交事务完成数 据更新前，主库将数据更新的事件记录到二进制日志中。MySQL会按事务提交的顺序 而非每条语句的执行顺序来记录二进制日志。在记录二进制日志后，主库会告诉存储引擎可以提交事务了。
下一步，备库将主库的二进制日志复制到其本地的中继日志中。首先，备库会启动一个 工作线程，称为I/O线程，I/O线程跟主库建立一个普通的客户端连接，然后在主库上启 动一个特殊的二进制转储(binhg dump、线程（该线程没有对应的SQL命令），这个二进制转储线程会读取主库上二进制日志中的事件。它不会对事件进行轮询。如果该线程追赶上了主库，它将进入睡眠状态，直到主库发送信号量通知其有新的事件产生时才会被唤醒，备库I/O线程会将接收到的事件记录到中继日志中。
备库的SQL线程执行最后一步，该线程从中继日志中读取事件并在备库执行，从而实现备库数据的更新。当SQL线程追赶上I/O线程时，中继日志通常已经在系统缓存中，所以中继日志的开销很低。SQL线程执行的事件也可以通过配置选项来决定是否写入其自己的二进制日志中，它对于我们稍后提到的场景非常有用。
主从同步的监控问题
Mysql有主从同步的状态信息，可以通过命令show slave status获取，除了获知当前是否主从同步正常工作，另外一个重要指标就是Seconds_Behind_Master，从字面理解，它表示当前MySQL主从数据的同步延迟，单位是秒。当主从同步停止以后，重新启动同步，这个数值可能会是几万秒，取决于主从同步停止的时间长短，我们可以认为数据此时有很多天没有同步了，而这个数值越接近零，则说明主从同步延迟最小，我们可以采集这个指标并汇聚曲线图，来分析我们的数据库的同步延迟曲线，然后根据此曲线，给出一个合理的阀值，主从同步的时延小于阀值时，我们认为从库是同步的，此时可以安全的从从库读取数据。