遇见MySQL 主从原理及问题的小tips

前言：今天单就MySQL主从及原理和遇到问题分析下，当然要支撑高并发仅仅靠MySQL是不可行的，目前我司用的是 MySQL+Nginx+redis+rabitMQ+elasticsearch+mongoDB等来支撑高并发；根据业务场景组合拳吧，下面进入正题.....

如果想从MySQL方便做到支持一定量的并发，那么必然会想到：读写分离

MySQL 做读写分离的前提，是把 MySQL 集群拆分成“主 + 从”结构的数据集群，这样才能实现程序上的读写分离，并且 MySQL 集群的主库、从库的数据是通过主从复制实现同步的。

在面试过程中，我们一般会被问到：

@1.你们公司MySQL有几台从库？每台从库作用是什么？(考察你对你用的系统熟悉程度)

@2.主从复制过程原理是什么？（考察你的基础知识）

总的来讲，MySQL 的主从复制依赖于 binlog ，也就是记录 MySQL 上的所有变化并以二进制形式保存在磁盘上。复制的过程就是将 binlog 中的数据从主库传输到从库上。这个过程一般是异步的，也就是主库上执行事务操作的线程不会等待复制 binlog 的线程同步完成。

1.目前我司一般是1主1从1备份，个别的实例和库会有多个从库；

2.主从复制大概分三个过程:

a:MySQL 主库在收到客户端提交事务的请求之后，会先写入 binlog，再提交事务，更新存储引擎中的数据，事务提交完成后，返回给客户端“操作成功”的响应。

b:从库会创建一个专门的 I/O 线程，连接主库的 log dump 线程，来接收主库的 binlog 日志，再把 binlog 信息写入 relay log 的中继日志里，再返回给主库“复制成功”的响应。

c:从库会创建一个用于回放 binlog 的线程，去读 relay log 中继日志，然后回放 binlog 更新存储引擎中的数据，最终实现主从的数据一致性。

下面找了张图：

在完成主从复制之后，你就可以在写数据时只写主库，在读数据时只读从库，这样即使写请求会锁表或者锁记录，也不会影响读请求的执行。

 

那么写入binlog日志记录数据方式有哪几种勒？

1. statement: 会将对数据库操作的sql语句写道binlog中
2. row: 会将每一条数据的变化写道binlog中。
3. mixed: statement与row的混合。Mysql决定何时写statement格式的binlog, 何时写row格式的binlog。（MySQL4.0版本后）

 

既然可以有多个从库，那大促流量大时，是不是只要多增加几台从库，就可以抗住大促的并发读请求了？why?

当然不是；因为：

从库数量增加，从库连接上来的 I/O 线程也比较多，主库也要创建同样多的 log dump 线程来处理复制的请求，对主库资源消耗比较高，同时还受限于主库的网络带宽。所以在实际使用中，一个主库一般跟 2～3 个从库（1 套数据库，1 主 2 从 1 备主），这就是一主多从的 MySQL 集群结构。

 

MySQL 主从复制还有哪些模型？

主要有三种；

@1：同步复制：事务线程要等待所有从库的复制成功响应。

@2：异步复制：事务线程完全不等待从库的复制成功响应。

@3：半同步复制：MySQL 5.7 版本之后增加的一种复制方式，介于两者之间，事务线程不用等待所有的从库复制成功响应，只要一部分复制成功响应回来就行，比如一主二从的集群，只要数据成功复制到任意一个从库上，主库的事务线程就可以返回给客户端。

 

主从必会遇到主从延迟问题，怎么解决？

@1：使用数据冗余；

         例：在异步调用A模块时，发送A模块需要的所有信息，借此避免在从库中重新查询数据。但要注意每次调用的参数大小，过大的消息会占用网络带宽和通信时间。

@2：使用缓存解决；（通过缓存解决 MySQL 主从复制延迟时，会出现数据库与缓存数据不一致的情况，所以这块要处理好）

@3：直接查询主库；（该方案在使用时一定要谨慎，你要提前明确查询的数据量不大，不然会出现主库写请求锁行，影响读请求的执行，最终对主库造成比较大的压力）