MySQL 主从复制原理
[!TIP|label:说明] MySQL主从复制涉及到三个线程，一个运行在主节点（log dump thread），其余两个(I/O thread, SQL thread)运行在从节点,当主节点有多个从节点时,对于每一个主从连接,主节点会为每一个当前连接的从节点建一个binary log dump 进程
- 主节点 binary log dump 线程 当从节点连接主节点时，主节点会创建一个log dump 线程，用于发送bin-log的内容。在读取bin-log中的操作时，此线程会对主节点上的bin-log加锁，当读取完成，甚至在发动给从节点之前，锁会被释放。
- 从节点I/O线程
当从节点上执行
start slave命令之后，从节点会创建一个I/O线程用来连接主节点，请求主库中更新的bin-log。I/O线程接收到主节点binlog dump 进程发来的更新之后，保存在本地relay-log中。 - 从节点SQL线程 SQL线程负责读取relay log中的内容，解析成具体的操作并执行，最终保证主从数据的一致性。
流程
数据库有个bin-log二进制文件，记录了所有sql语句。
- binlog输出线程:每当有从库连接到主库的时候，主库都会创建一个线程然后发送binlog内容到从库。在从库里，当复制开始的时候，从库就会创建两个线程进行处理：
- 从库创建一个I/O线程，该线程连接到主库并请求主库发送binlog里面的更新记录到从库上。从库I/O线程读取主库的binlog输出线程发送的更新并拷贝这些更新到本地文件，其中包括relay log文件。
- 从库的SQL线程:从库创建一个SQL线程，这个线程读取从库I/O线程写到relay log的更新事件并执行。
问题&解决
- 主库宕机后，数据丢失
半同步复制
- 主库写压力大，因从库只有一个sql 线程来持久化，复制可能延迟
并行复制
- 复制出错处理 常见：1062（主键冲突），1032（记录不存在）
手动处理 OR 跳过复制错误：set global sql_slave_skip_counter=1
主从复制延迟
- 主节点如果执行一个很大的事务(更新千万行语句，总之执行很长时间的事务)，那么就会对主从延迟产生较大的影响
- 网络延迟，日志较大，slave数量过多。
- 主上多线程写入，从节点只有单线程恢复
处理办法：
- 大事务：将大事务分为小事务，分批更新数据。
- 减少Slave的数量，不要超过5个，减少单次事务的大小。
- MySQL 5.7之后，可以使用多线程复制，使用MGR复制架构
半同步复制
原理:事务在主库写完binlog后需要从库返回一个已接受，才放回给客户端
- 5.5集成到mysql，以插件的形式存在，需要单独安装
- 确保事务提交后binlog至少传输到一个从库
- 不保证从库应用完成这个事务的binlog
- 性能有一定的降低
- 网络异常或从库宕机，卡主库，直到超时或从库恢复
并行复制
原理：从库多线程apply binlog
- 在社区5.6中新增
- 库级别并行应用binlog，同一个库数据更改还是串行的
- 5.7版本并行复制基于事务组
联级复制（部分数据复制）
- A->B->C
- B中添加参数log_slave_updates
- B将把A的binlog记录到自己的binlog日志中