Mysql专栏收尾之作，作为一名后端开发人员，对于Mysql的知识了解到这里已经足以应对99的场景了，毕竟没有必要非要跟DBA抢活儿干。
而且现在的趋势都是往云上走，云数据库已经帮我们处理了高可用和数据一致性的事情了，所以当扩展知识了解就好，实际应用场景几乎没有，在本篇文章中并没有给出具体的配置实现。
Mysql热备
Mysql自身提供了数据复制的方式-主从同步。
基于Mysql的主从同步，我们可以生成数据库的很多副本，这时候加上keepalived做个热备，就可以基本满足Mysql的高可用要求了。
但是主从同步必然会损失数据一致性，所以实际应用场景来讲，顶多做几个读库来实现读写分离，而不是为了高可用，因为数据库的一致性是至关重要的。
Mysql主从同步
这里特指Mysql5.7版本，5.6、5.7、8.0都有些差异点，而且目前主要使用的都是5.7，对于其他版本接触不多。
Mysql主从复制基础来源于binlog，所以一定要开启binlog，而且在5.7版本，对于binlog提供了新的id增强：gtid，极大的简化了对于binlog复制过程的排查和纠错难度，建议开启。（之前数据恢复什么的，都得用binlog的位点信息 logfile + logposition，如果开了gtid只用gtid就行了）
当开启binlog后，在mysql控制台中
整个同步流程如上图所示，当slave开启了主从复制后，会使用当前的位点信息向master发送请求。
master会为每个slave启动一个dump线程，如果当前的binlog位点大于slave请求的位点就向slave发送binlog日志。
slave中会启动一个io线程用于接收binlog日志写到磁盘的relay_log日志中，并同时维护当前slave的位点信息。
slave也会启动一个sql线程从relay_log日志中获取binlog进行重放数据。
默认情况下，master的dump线程不会关心slave的接收状态，所以一般来讲，主从复制也可称为异步复制。
Mysql半同步复制
上面提到了，Mysql自身的同步复制属于异步复制，也就是master是不关心数据有没有真正到从库的，你给我发请求拉取，我就给你binlog数据，仅此而已，所以是无法保障数据一致性的。
因此Mysql又提供了一种半同步复制方案（以插件模式支持，具体配置可以查阅其他文章）。
半同步复制在主从同步的基础上，需要从库返回ack响应。也就是需要slave明确收到了数据后，master才能进行提交事务（5.7特性 Loss-less Semi-Synchronous）当然有利也有弊，该方案提升了数据一致性的同时，也会对Mysql的性能产生影响，因为每个事务都需要进行二次传播（同步到从库上）
为了尽可能减小半同步复制对主库的影响，当从库断联时，会自动降级为异步复制，所以该方案也不是追求完全数据一致性的。
半同步复制要求主库、从库都要开启，其中只要一个未开启则降级为异步复制。
附录
1 Loss-less Semi-Synchronous
5.7之前，半同步复制中事务的二次传播是发生在主库事务提交之后进行的。也就是如果主库在等待从库ack过程中发生异常了，这时主库其实已经把事务给提交了，主库的客户端是能感知到这个事务的，但是在从库上是没有该事务的，会造成主从数据不一致。
5.7默认在事务提交前等待从库ack，来尽可能保证主从两边的事务一致。
