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

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

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

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

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

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

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

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

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

主从延迟

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

对一致性要求极端高的读访问，可能需要访问主库，但是这会加重主库的负载，要谨慎操作。避免大事务操作，必要的时候提交事务，延迟一定时间再继续更新。注意对主从延迟的监控，从而及时发现和处理问题。
本文转自网络，原文链接：https://developer.aliyun.com/article/784916
本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！