Mysql集群及高可用-主从工作原理3

系列文章目录

Mysql集群及高可用-主从工作原理3

---

---

一、重启服务器需要检查的模块

1.服务器重启后，重新启动数据库
2.server1查看master状态 show master status
3.server2、3查看slave状态show slave status\G;
io线程错误时候，一般是认证的问题
可以看错误日志,就在show slave status\G;这里可以查看到

---

二、主从工作原理

server1：
进入数据库
因为a->b,a->c（上个文章2，配置的gtid）
所以有2个Binlog Dump

---

server2、3:

第一个Waiting是io线程，第二个Slave是SQL线程

---

master端并行的进行写入（读写都可）

1.slave 经过认证，建立主从复制
2.主有一个线程Binlog Dump，发现Binlog变更后，发送binlog update
3.slave io 和 sql线程，Io收到二进制日志后会存到本地数据目录的relaylog里面（SQL读，io写）

通过relay-bin.index来索引，存储所有的relaylog，这样数据库加载的时候不会丢失，按照顺序进行加载（同理Binlog日志）

---

整个过程是异步的
master端：send binlog update
slave端：io线程接收，存入disk,是理想状态
binlog发送过程可能出现网络问题，slave断开等等

所有需要一个确认机制ack
当slave端：io线程接收，存入disk后，给master发送ack,这个时候Master才会继续引擎提交

该方法称为半同步，默认情况半同步是10s，10s内master收不到ack，master会变成异步模式工作，这样可能导致集群主从不一致

如果想始终是半同步，那就调整半同步时间无穷大，这样的话master就无法工作了（写入不了）一直等待slave的ack，在ack到达之前，不会引擎提交（外部看不见ok），客户端一直卡着

对于数据库而言，你先引擎提交后，才能在客户端看见ok

---

master接收ack后，sql线程开始复原sql语句

Io和sql线程是独立工作的，io只复制接收和存储（通过网络发送的纯数据，数据量很小，所以非常快）性能高，sql负责读relog（单线程）

master有N个用户并行写入，sql单线程回放，master写入快，所以io存的越来越多，sql赶不上io的速度，会造成延迟，slave端show slave status\G;
这个值越来越大，表示延迟大

long-slave-updates参数做完sql回放后（relog），再次写入Binlog
就是a->b->c

---

三、ok过程详情细节（半同步模式）原理

用户在提交后（比如insert into）写入Binlog(在数据库系统里面，可以理解在缓存)
Binlog Dump 线程发现Binlog变更了，push 二进制日志给slave端的io线程

异步状态直接同步（就没有确认动作了）

做Sync是从内存刷磁盘，如果是机械盘，数据库变更，频繁变更，频繁刷磁盘，会形成热点，性能会下降很快，所以需要换固态
nosql快因为key value的引擎运行在内存中（如memache、redis）（redis相对于memache有持久化）只要有刷磁盘的动作都是消耗磁盘Io的动作，磁盘io不快，就会形成热点对数据库性能影响很大

数据库引擎提交，先刷再引擎提交（保证数据不丢失），默认情况同步二进制日志，每个事件刷一次，你每写一次，刷一次，目的就是保证数据一致性，一旦内部引擎提交后，其他用户线程是并发的，比如A用户插入的数据，其余用户就可以select看到

最后Io给予确认ack，当收到ack后才会发聩给客户端Ok

---

四、半同步模式5.7以前对比（AFTER_COMMIT与AFTER_SYNC）

横线上面都一样，但是是用户可以在master没有收到slave的ack的时候就开始提交
这样会造成一个问题
比如slave没有发ack，master这边用户提交了然后挂了，有主备切换，切到slave，slave变成新的master，就没有之前master提交的数据

AFTER_SYNC
slave端没有接受到数据（没有发送ack），master端也看不到，即使刷盘，系统引擎没有提交，其他用户看不到这笔数据的
只有引擎提交后，其他用户才能查看到该数据

---

END