【博客243】简述：数据库的主从同步

内容： 简述数据库的主从同步如何实现

主从同步：

主从的引入：
为了解决当主节点宕机时，引起数据的丢失，往往会在一个主节点启动多个从结点来进行备份

同步：
既然是备份，那么就有一个备份的过程，而在这个备份的过程中，数据属于过度态，因此出现同步问题

主从同步的实现：

实现步骤：
当客户端提交一个事务到数据库的集群，直到客户端收到集群返回成功响应，在这个过程中，数据库集群
需要执行很多操作：主库需要提交事务、更新存储引擎中的数据、把Binlog 写到磁盘上、给客户端返回
响应、把 Binlog 复制到所有从库上、每个从库需要把复制过来的 Binlog 写到暂存日志中、回放这个
Binlog、更新存储引擎中的数据、给主库返回复制成功的响应。

注意：这些操作的时序非常重要：这里面的“时序”就是这些操作的先后顺序。同样的操作，因为时序不同，
对应用程序来说，有很大的差异，不仅性能上差异巨大，而且安全性差异也很大。比如说，如果先复制 
Binlog，等Binlog 复制到从节点上之后，主节点再去提交事务，这种情况下，从节点的 Binlog 一直和
主节点是同步的，任何情况下主节点宕机也不会丢数据。但如果把这个时序倒过来，先提交事务再复制 
Binlog，性能就会非常好，但是存在丢数据的风险。

MYSQL的主从同步：

MySQL 提供了几个参数来配置这个时序，默认情况下：MySQL 采用异步复制的方式，执行事务操作的线程
不会等复制 Binlog 的线程。

过程：
MySQL 主库在收到客户端提交事务的请求之后，会先写入 Binlog，然后再提交事务，更新存储引擎中的
数据，事务提交完成后，给客户端返回操作成功的响应。同时，从库会有一个专门的复制线程，从主库接收
Binlog，然后把 Binlog 写到一个中继日志里面，再给主库返回复制成功的响应。从库还有另外一个回放
Binlog 的线程，去读中继日志，然后回放 Binlog 更新存储引擎中的数据。提交事务和复制这两个流程
在不同的线程中执行，互相不会等待，这是异步复制。

在异步复制的情况下，为什么主库宕机存在丢数据的风险？为什么读写分离存在读到脏数据的问题？
原因：异步复制它没有办法保证数据能第一时间复制到从库上。

与异步复制相对的就是同步复制：
同步复制的时序和异步复制基本是一样的，唯一的区别是，什么时候给客户端返回响应。异步复制时，
主库提交事务之后，就会给客户端返回响应；而同步复制时，主库在提交事务的时候，会等待数据复制
到所有从库之后，再给客户端返回响应。


同步复制在实际应用中极少使用：
原因：
1、是性能很差，因为要复制到所有节点才返回响应，用户体验不佳
2、是可用性也很差，主库和所有从库任何一个数据库出问题，都会影响业务。

为了解决这个问题，MySQL 从 5.7 版本开始，增加一种半同步复制的方式：
1、异步复制是，事务线程完全不等复制响应；
2、同步复制是，事务线程要等待所有的复制响应；
3、半同步复制介于二者之间，事务线程不用等着所有的复制成功响应，只要一部分复制响应回来之后，
就可以给客户端返回了。

比如说，一主二从的集群，配置成半同步复制，只要数据成功复制到任意一个从库上，主库的事务线程
就直接返回了。这种半同步复制的方式，它兼顾了异步复制和同步复制的优点。如果主库宕机，至少还
有一个从库有最新的数据，不存在丢数据的风险。并且，半同步复制的性能也还凑合，也能提供高可用
保证，从库宕机也不会影响主库提供服务。所以，半同步复制这种折中的复制方式，也是一种不错的选择。


在实际应用过程中，选择半同步复制需要特别注意：

1、配置半同步复制的时候，有一个重要的参数“rpl_semi_sync_master_wait_no_slave”，
含义是：“至少等待数据复制到几个从节点再返回”。这个数量配置的越大，丢数据的风险
越小，但是集群的性能和可用性就越差。最大可以配置成和从节点的数量一样，这样就变成
了同步复制。


一般情况下：
配成默认值 1 也就够了，这样性能损失最小，可用性也很高，只要还有一个从库活着，就不影响
主库读写。丢数据的风险也不大，只有在恰好主库和那个有最新数据的从库一起坏掉的情况下，
才有可能丢数据。

2、另一个重要的参数是“rpl_semi_sync_master_wait_point”，这个参数控制主库执行事
务的线程，是在提交事务之前（AFTER_SYNC）等待复制，还是在提交事务之后（AFTER_COMMIT）
等待复制。默认是 AFTER_SYNC，也就是先等待复制，再提交事务，这样完全不会丢数据。
AFTER_COMMIT 具有更好的性能，不会长时间锁表，但还是存在宕机丢数据的风险。

3、配置了同步或者半同步复制，并且要等待复制成功后再提交事务，还是有一种特别容易被忽略、
可能存在丢数据风险的情况。

举例：主库提交事务的线程等待复制的时间超时了，这种情况下事务仍然会被正常提交。并且，MySQL
 会自动降级为异步复制模式，直到有足够多（rpl_semi_sync_master_wait_no_slave）的从库追
 上主库，才能恢复成半同步复制。如果这个期间主库宕机，仍然存在丢数据的风险。

复制状态机：所有分布式存储都是这么复制数据的

在 MySQL 中，无论是复制还是备份恢复，依赖的都是全量备份和 Binlog，全量备份相当于备份那一时刻
的一个数据快照，Binlog 则记录了每次数据更新的变化，也就是操作日志。虽然讲的都是 MySQL，但是
你这种基于“快照 + 操作日志”的方法，不是 MySQL 特有的。比如说，Redis Cluster 中，它的全量备
份称为 Snapshot，操作日志叫 backlog，它的主从复制方式几乎和 MySQL 是一模一样的。

比如：redis中的AOF和RDB方式持久化，在新版的redis中采用的混合持久化方式也是这个原理。就是将
redis的数据快照以RDB形式备份，对新增写入以AOF日志方式备份，开机的时候需要将RDB文件读入以还原
旧的数据，然后再将AOF形式的写入命令进行重放即可。注意：此时并不是有AOF和RDB两种文件，而是备份
文件的开头是RDB形式的，接下来是AOF形式的，前半部分RDB形式是快照，后半部分AOF格式的是新增写入
的命令，等待你去重放。