复制解决的基本问题是让一台服务器的数据和其他服务器保持同步。一台主服务器的数据可以同步到多台从服务器上。并且从服务器也可以被配置为另外一台服务器的主库。主库和从库之间可以有多种不同的组合方式。
MySQL支持两种复制方案：基于语句的复制（statement-based replication）和基于行的复制（Row-based replication）。基于语句的复制在MySQL3.23就已经存在，它是使用较多的复制方式。基于行的复制是MySQL5.1引入的。这2种复制方式都是通过记录主服务器的二进制日志，并在从服务器进行重放（replay）完成复制。它们都是异步的。也就是说，从服务器上的数据并非都是最新的。
复制通常不会增加主库的开销，主要是启用二进制日志带来的开销，但出于备份戒及时从崩溃中恢复的目的，这些开销是必要的。通过复制可以将读操作指向从库来获得更好的读扩展，但对于写操作，并不适合通过复制来扩展。
1、mysql复制用途
- 分布数据
MySQL通常不会对带宽造成很大的压力。因此可以在不同的地理位置来分布数据，实现跨机房跨地域的数据分布。
- 负载均衡
通过MySQL复制可以将读操作分布到多个服务器上，实现对读密集型应用的优化。
- 备份
复制对备份很有帮助，但是从服务器并不是备份。
- 高可用性和故障转移
复制可以避免在应用程序中出现MySQL失效。好癿故隓转移能显著的减少停机时间，甚至让用户无感知。
- 测试MySQL版本升级
一个常见的方法是先把从服务器升级到MySQL新版本，然后用它来测试查询，确保无异常后再升级主服务器
2、案例：客户投诉：修改了xx信息，提示修改成功。再查看还是旧数据。怎么回事？
很有可能是数据库主从延迟造成的
3、MySQL主从延时延时问题如何处理?
1.偶发性延时：控制写入速度，削峰填谷。
2.频发性延时：拆分数据库实现多点写入
3.最后一招：从库磁盘硬件升级为ssd
4、 mysql主从复制的过程是怎样的呢？如下图所示
3个线程完成复制：
- 主库1个线程负责记录数据库变更日志
- 从库1个线程负责拉取主库的变更日志
- 从库1个线程负责执行主库的变更日志
- 实现了获取事件和重放事件的解耦，允许异步进行。
- 复制的瓶颈：主库并行(多线程)写入和从库串行（单线程）写入，会造成主从延迟。