MySQL

主从复制

主从复制原理

流程

主库在收到客户端提交事务的请求之后，会先写入binlog，再提交事务、更新存储引擎中的数据，事务提交完成后，返回给客户端"操作成功"的响应。从库同步时会开启两条线程，一条用来连接主库的log dump线程，接收主库的binlog日志，写入从库的relaylog中继日志，再返回给主库"复制成功"的响应；另一条用来根据relaylog更新存储引擎的数据。
总结一下，写入binlog——同步binlog到RelayLog——回放RelayLog

锁

log dump线程开启时会被加上锁，这个锁只管读，不会妨碍主库写数据到binlog；而且这个锁从5.7后从锁IO线程的整个事件变成锁Binlog文件末尾的那个位置点，只有读到那才会被锁。

异步和串行化

主写binlog和传给从两个线程异步，主传给从成功与否，主写完binlog都会给客户端返回成功的响应。如果从宕机没收到这部分事务的提交会丢失，所以使用半同步复制作为折中方案。从读relaylog更新数据是串行的，只能一行行执行log。

读写分离

1.写操作到主库，读操作到从库

2.主从延迟

原因

（1）传输中：网络瓶颈，带宽不足
避免跨机房跨地域部署，物理距离造成的带宽不足
开启binlog压缩 binlog_compression = ON，减小传输体积
（2）源头：主库
● 并发写入量太大
优化业务逻辑、优化慢sql、不适合采用读写分离结构，应该分库分表或者数据库集群
● 执行大事务
拆解大事务，例：单次处理10万行的操作，改成每次处理1000行的循环，避免一次大量binlog瞬间占满网络，缩短从库回放事务时间
（3）消费：从库速度跟不上主库
提升从库硬件
单线程串行回放改成多线程并发写入

排查

从库执行 SHOW SLAVE STATUS\G，观察指标：
Seconds_Behind_Master：为0一般没问题，如果忽大忽小或周期性波动，可能是网络抖动或有大事务；如果值稳定增长，可能是从库处理不过来
Slave_IO_Running / Slave_SQL_Running：必须都是Yes，有线程断就会有延迟

3.数据一致性

读写分离情况下，解决主从同步中数据不一致，就是解决主从之间数据复制方式

异步复制

主库提交事务、写Binlog后，不等待从库确认，返回成功给客户端。
默认的复制方式，性能高，但主库故障时未同步到从库的数据会丢失

半同步复制

主库提交事务后，等待至少一个从库确认收到Binlog并写入RelayLog，才向客户端返回成功。如果超时没收到确认，就自动降级回异步模式。
数据更安全，但增加等待确认时间的延迟

组复制 MGR

5.7后推出，集群形式才适用
事务提交前，同意节点数量大于(N/2+1）时才能提交。只要多数节点存活，系统就可用且数据零丢失。

参考
https://zhuanlan.zhihu.com/p/21800324298