浅谈Mysql原理与优化（六）—— 主从复制

MySQL最简单的部署是单机部署，即在一个服务器上部署一个MySQL实例，简单方便。但是这样部署的缺点也很明显：

1. 缺乏冗余，数据库为单点，数据库故障将影响整个服务不可用
2. 如果磁盘损坏将造成重要数据的永久丢失
3. 缺乏扩展性，当服务器压力曾增长时无法扩展

所以MySQL提供了一项方便的功能，主从复制，可以建立一个主库，多个从库的拓扑结构，以解决以上几个问题。下图便是主从复制结构的架构图

上边为Web服务器架构，通常用负载均衡实现多个Web服务器承接流量
红色框内为数据库架构：

1. 主库承接所有web服务器的写请求
2. 主库将数据同步到多个从库上，即从库和主库有着一致的数据，主库和从库共同承接所有的读请求。

通常来说写请求要远远小于读请求，可以设想一下，通常我们访问网站，90%以上的时间在浏览信息，只有很少的时候会提交表单修改数据库，所以这个架构对于绝大部分网络应用还是比较合适的。

主从复制的原理
那么从主库到从库的数据同步是怎么实现的呢，我们可以看下图

首先主库所有的数据变更会写到本地服务器的binlog文件中，这也是数据库本身数据可恢复性的要求。然后远程的从库会有一个IO线程，从主库拉取所有未同步的binlog，同步到本地，然后从库的另一个SQL线程回放binlog，向从库的数据应用最新的数据修改，从而完成数据同步，实现数据的一致性

主从延迟

由于这套架构实现了主库和从库的解耦，也就是说主库的更新并不依赖于从库的同步。所以主库会马上更新完成，然后通过网络再发送给从库，从库实际上是有一定的延迟的。
如果数据更新量非常的大，尤其是在一个事务中的时候，从库的延迟可能会加剧，可能会从原本的几十毫秒上升到几秒甚至更多。
主从延迟的优化主要有以下办法：

1. 对一致性要求极端高的读访问，可能需要访问主库，但是这会加重主库的负载，要谨慎操作。
2. 避免大事务操作，必要的时候提交事务，延迟一定时间再继续更新。
3. 注意对主从延迟的监控，从而及时发现和处理问题。