8 关于集群

1 MySQL的主备

基本的主备切换流程：M-S结构

备库设置成只读，怎么写入主库的写操作，保持同步更新：readonly设置对超级(super)权限用户是无效的，而用于同步更新的线程，就拥有超级权限。

update语句在节点A执行，然后同步到节点B的完整流程图：

实际生产上使用比较多的是双M结构：这样切换的时候就不用再修改主备问题

不过会有一个循环复制问题：业务逻辑在节点A上更新了⼀条语句，然后再把生成的binlog 发给节点B，节点B执行完这条更新语句后也会生成binlog；
节点A同时是节点B的备库，相当于又把节点B新生成的binlog拿过来执行了⼀次，然后节点A和B间，会不断地循
环执行这个更新语句。

解决：

1. 规定两个库的server id必须不同，如果相同，则它们之间不能设定为主备关系；
2. ⼀个备库接到binlog并在重放的过程中，生成与原binlog的server id相同的新的binlog；
3. 每个库在收到从自己的主库发过来的日志后，先判断server id，如果跟自己的相同，表示这个日志是自己生成的，就直接丢弃这个日志。

因此日志的执行流程为：

1. 从节点A更新的事务，binlog里面记的都是A的server id；
2. 传到节点B执行⼀次以后，节点B生成的binlog 的server id也是A的server id；
3. 再传回给节点A，A判断到这个server id与自己的相同，就不会再处理这个⽇志。所以，死循环在这里就断掉了。

2 高可用

正常情况下，只要主库执行更新生成的所有binlog，都可以传到备库并被正确地执行，备库就能达到跟主库⼀致的状态，这就是最终⼀致性：

但是，MySQL要提供高可用能力，只有最终⼀致性是不够的

2.1 主备延迟

数据同步的流程：

1. 主库A执行完成⼀个事务，写⼊binlog：把这个时刻记为T1;
2. 之后传给备库B，把备库B接收完这个binlog的时刻记为T2;
3. 备库B执行完成这个事务：把这个时刻记为T3。

主备延迟：同⼀个事务，在备库执行完成的时间和主库执行完成的时间之间的差值，也就是T3-T1（也就是seconds_behind_maste，表示当前备库延迟了多少秒）。

主备延迟大主要是因为1和3（网络好的情况下可以忽略2），最直接的表现就是备库消费中转日志（relay log）的速度，比主库生产binlog的速度要慢。

原因：

1 备库所在机器的性能要比主库所在的机器性能差：可以加强机器

2 备库的压力大，比如读操作多：可以一主多从、通过binlog输出到外部系统，比如Hadoop这类系统，让外部系统提供统计类查询的能力

3 大事务，因为主库上必须等事务执行完成才会写入binlog，再传给备库，所以，如果⼀个主库上的语句执行10分钟，那这个事务很可能就会导致从库延迟10分钟。

比如：⼀次性地用delete语句删除太多数据、大表DDL

4 备库的并行复制能力

2.2 策略

由于主备延迟的存在，所以在主备切换的时候，就相应地有不同的策略。

2.2.1 可靠性优先策略

1. 判断备库B现在的seconds_behind_master，如果小于某个值（比如5秒）则继续下⼀步，否则持续重试这⼀步；
2. 把主库A改成只读状态，即把readonly设置为true；
3. 判断备库B的seconds_behind_master的值，直到这个值变成0为止；（前三步是为了主备数据同步）
4. 把备库B改成可读写状态，也就是把readonly 设置为false；
5. 把业务请求切到备库B。
   

2.2.2 可用性优先策略

如果强行把步骤4、5调整到最开始执行，也就是说不等主备数据同步，直接把连接切到备库B，并且让备库B可以读写，那么系统几乎就没有不可用时间了

可能产生数据不⼀致：

初始化：

CREATE TABLE `t` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`c` int(11) unsigned DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB;

insert into t(c) values(1),(2),(3);

执行sql：

insert into t(c) values(4);
insert into t(c) values(5);

假设现在主库上其他的数据表有大量的更新，导致主备延迟达到5秒。在插⼊⼀条c=4的语句后，发起了主备切换：binlog_format=mixed