如何做主从同步?

mysql如何做的副本同步？

mysql的主服务器叫做master，从服务器叫做slave。

主服务器将变更记录在binlog中，slave将通过独立的线程拷贝这些记录，然后重放。

binlog的格式分为statement、row、mixed三种。

• statement 将变更的sql语句写入到binlog中，在准确性方面会有一定影响

• row 将每一条记录的变化，写入到binlog中

• mixed 上面两种的结合。MySQL会判断什么时候有用statement，什么时候用row

由于是异步线程去拷贝，slave很容易会出现延迟。当master不幸宕机，将会造成延迟的数据丢失。

为了解决异步复制的问题，5.5版本之后，MySQL引入了半同步复制（semi  sync）的概念。半同步处于异步和全量同步之间，master执行完事务之后，并不直接返回，而是要等待至少一个slave写入成功才返回。由于需要与至少一个slave进行交互，性能相比较异步复制肯定是有不少折损的。

全复制模式当然是要等待所有的slave节点复制完成，这种安全性最高，但是效率也最低。从概念上来讲，只有一个slave的半复制就是全复制。

5.7之后，mysql实现了组复制（group replication）协议。它支持单主模式和多主模式，但在同一个group内，不允许同时存在。听起还好像很神奇，其实它还是通过paxos协议去实现的。

Kafka如何做的副本同步？

kafka由于是一个消息队列，所以不需要考虑随机删除和随机更新的问题，它只关注写入问题即可。从结构上来说，kafka的同步单元是非常分散的：kafka有多个topic，每个topic又分为多个partition，副本就是基于partiton去做的。

主分区叫做leader，1-n个副本叫做follower。生产者在发送消息的时候，需要先找到该分区的leader，然后将数据发送给它。follower只是作为一个备份存在，以便在主分区发生问题时能够顶上去。

kafka的主从同步，叫做ISR（In Sync Replica）机制。

那什么时候消息算是发送成功呢？这还要看ack的发送级别。

• 0 表示异步发送，消息发送完毕就算是成功了

• 1 leader主副本写入完成，就算是发送成功了

• -1 leader发送完成，并且ISR中的副本都需要回复ack

0和1的情况下，kafka都有丢失消息的可能。在-1的情况下，也需要保证至少有一个follower commit成功才能保证消息安全。如果follower都不能追赶上leader，则会被移除出 ISR列表。没错，是直接移除。当ISR为空，则kafka的分区和单机是没有区别的，所以kafka提供了min.insync.replicas参数规定了最小ISR。

• 当ISR不满足的时候怎么办？kafka当然是不会丢失消息了，因为此时生产者的提交是失败的，消息根本进不了系统里来

• 当所有副本都不可用怎么办？此时，该partition将永不可用

副本之间的数据复制，是通过follower pull的方式，也就是拉取的方式去获取的。

Redis的主从复制

redis是内存kv数据库，速度上远超其他数据库，理论上主从同步更容易。但在高流量和高QPS下，主从复制依然会发生问题。

redis的slave连接上之后，首先会进行一次全量同步。它会发送psync命令到master，然后master执行bgsave生成一个rdb文件。全量同步就是复制这个rdb快照文件到slave。

那在全量复制中间出现的数据怎么办呢？肯定是要缓存起来的。master会开启一个buffer，然后记录全量复制过程中产生的新数据，在全量同步完成之后再补齐增量数据。

slave断线之后也不需要每次都执行全量同步，为了配合增量，还引入了复制偏移量（offset）、复制积压缓冲区（replication backlog buffer）和运行 ID （run_id）三个概念。可以看出它都是为了标识slave，以及它的复制位置和缓冲区用的。

之后的同步，就可以一直使用psync去复制。依然是异步复制。

可以看出redis的主从复制一致性大量依赖内存，级别是非常弱的。但是它快。快能解决很多问题，所以应用场景是不同的。

ElasticSearch主从复制

es是基于lucene的搜索引擎，数据节点会包含多个索引（index）。每个索引包含多个分片（shard），每个分片又包含多个replica（副本）。

从上面的描述来看，这些概念是与kafka高度雷同的，es的复制单元是分片。

es的数据依然是先写master，它同样维护了一个同步中的slave列表（InSyncAllocationIds），处于yellow和red状态的副本当然是不在这个列表中的。

master需要等待所有这些正常的副本写入完成后，才返回给客户端，所以一致性级别是比较高的，因为它的slave节点是要参与读操作的，它是一个近实时系统。

由于它是一个数据库，所以依然会有删除和更新操作。Translog相当于wal日志，保证了断电的数据安全，这和其他rdbms的套路是一致的。

MongoDB主从复制

mongodb有三种数据冗余方式。一种是master-slave（不推荐使用），一种是replica set，一种是 sharding模式。

mongodb的副本集主从，就是标准的故障自动转移实现方式，不需要人工介入。master节点当掉之后，会通过选举从副本集中找出新的master节点，然后引导其他节点连接到这个master。

mongodb的选举算法，采用的是bully。

主节点的变更，会存放在特定的系统表中。slave会定时拉取这些变更，并应用。从这种描述中也可以看出，mongodb在同步延迟或者单节点出问题的时候，会有丢失数据的可能。

总结

分布式是为了解决单机的容量问题，但它引入了一个新的问题，那就是数据同步。

数据同步要关注一致性，故障恢复以及时效性。

主要有两种数据需要同步。

• 元数据信息

• 真正的数据

对于元数据信息，目前比较主流的做法，可以参考使用raft协议进行数据分发。到了真正的数据同步方面，raft协议的效率还是有些低的，所以会普遍采用异步复制的方式。

在这种情况下，异步复制列表，就成了关键的元数据信息，集群需要维护这些节点的状态。最坏的情况下，异步复制节点全部不可用，master会自己运行在非常不可信的环境下。

为了增加数据分配的灵活性，这些复制单元多会针对于sharding分片进行操作，由此带来的，就是meta信息的爆炸。