花十分钟了解一下MySql主从复制策略

1: 为什么需要高可用

MySql单机是可以使用，但是如果有一天MySql突然挂了，那么整个服务就都不可用了，这是不能接受的，总得有个兜底的方案

2：MySql高可用

MySql高可用也就是要保证即使有一台服务器挂了，也要保证服务能正常运行，所以在生产环境下至少也要保证有 一主一从 的架构，既然涉及到了主从，那么就会有数据同步的问题，MySql提供了几种数据同步策略

3：MySql主从复制原理

在主从进行同步过程中会涉及到三个线程：

• 从库的I/O线程：主要是获取主库的binlog日志,获取到日志之后将日志写到relay log日志文件中
• 从库的sql线程：读取relay log日志内容，解析成sql执行，其实就是执行主库的sql
• 主库的log dump线程：读取主库的新增的binlog日志文件内容，发送给从库

4: 主从同步策略

4.1：全同步复制

客户端执行SQL时候，必须等到所有从库和主库都提交成功之后才能返回响应给客户端

• 优点：可以保证数据不丢失

• 缺点：效率很低，随着机器的增加，执行的效率会越来越低，因为要同步的机器有很多，只有等所有机 器都提交之后才能返回响应给客户端

4.2：异步复制

客户端执行SQL之后，只会通知线程将binlog日志发送给从库，主库直接提交，不会等从库的响应，效率很高

• 优点：效率高
• 缺点：数据会丢失，如果这同步的时候，主库提交了，但是由于一些原因导致从库并没有获取到主库发送过来的binlog日志，这时候主库挂了，那么这条数据在从库就找不到了
• 适用场景：数据安全性不高，效率很高的场景

4.3：半同步复制

客户端执行SQL之后，至少要有一个从库同步成功才能返回响应给客户端，也就是说即使现在主库挂了，那么从库还是有这条数据

在全同步与异步取了折中的方案

5：传统复制

在传统主从复制过程中，当主库执行行了一个事务，那么在binlog文件中就会记录该事务开始的position和结束的position，这也是为什么在配置传统主从复制中，从库要配置主库文件的position，也就是从哪个位置开始进行同步。接下来只要binglog有变化就会将binlong日志同步给从节点

5：GTID复制

在MySql5.6之后提供了GTID复制。 GTID全程是 Global Trancation ID，是由MySql机器的唯一id+TID组成的，TID是当前MySql实例已经提交的事务数量，是逐渐递增的。

Matser在更新数据之前就会生成一个GTID，一同记录到binlog中，再将binlog同步给Slave之后，Slave会先拿到GTID，然后判断这个GTID是否已经被处理过，如果被处理过就忽略，如果没有就执行

5.1:GTID的优势：

• 不需要再去找position进行同步了
• 比传统复制简单

8：多源复制

多源复制可以将多个MySql实例的数据合并到一个MySql实例上，但是多源复制不会解决冲突问题，比如数据库名重名等等，需要在程序中自行解决