复制解决的基本问题是让一台服务器的数据和其他服务器保持同步。一台主服务器的数据可以同步到多台从服务器上。并且从服务器也可以被配置为另外一台服务器的主库。主库和从库之间可以有多种不同的组合方式。
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个线程负责执行主库的变更日志
实现了获取事件和重放事件的解耦,允许异步进行。
复制的瓶颈:主库并行(多线程)写入和从库串行(单线程)写入,会造成主从延迟。