数据库复制原理 - 主从同步

@author：zxw

@email：502513206@qq.com

@ Jishou University

参考：Designing Data-Intensive Applications

---

前言

复制主要是指通过互联网络在多台机器上保存相同的数据副本，为了实现以下效果

1. 使数据在地理位置上更接近用户，从而降低访问延迟
2. 当部分组件出现故障，系统依然可以继续工作，提高可用性
3. 多台机器同时提供读服务，提高吞吐量

如果数据是一成不变的，那么复制就非常容易。但是我们平常数据处于经常变更的状态下，就比较难处理。目前主流的三种复制变化的数据的方式有：主从复制、多主节点复制、无主节点复制。几乎所有的分布式数据库都采用上述方法的一种

主从复制

每个保存数据库完整数据集的节点称之为副本，那么多副本之间的数据如何保证一致？对于每条数据的写入所有副本需要随之更新，否则某些副本将出现不一致的情况，以下为主从复制原理：

1. 指定某一副本为主副本，当写入数据库时，必须将写请求首先发给主副本，主副本首先将新数据写入本地存储
2. 其他副本则全部称为从副本。主副本把数据写入本地存储后，然后将数据更改作为复制的日志或更改流发送给所有从副本，每个从副本获得更改日志之后将其应用到本地，且严格保持与主副本相同的写入顺序
3. 客户端从数据库读取数据是，可以在主副本或从副本上执行查询。再次强调只有主副本可以接受写请求
   

同步复制与异步复制

复制非常重要的一个设计就是同步还是异步，对于关系数据库系统，同步或异步通常是一个可配置的选项。

同步复制：

• 优点
  1. 可以保证主节点可从节点的更新同步，数据是最新的。
  2. 如果主节点发生故障，总是可以从从节点访问最新的数据
• 缺点
  1. 如果从节点不能完成确认(如节点故障、网络故障等)，写入就不能视为成功，主节点会阻塞其后的所有写操作
  2. 如果存在多个从节点需要同步数据，那么吞吐量会逐渐降低，并且响应延迟增加。

那么现在我们知道同步复制比较耗时，并且随着从节点数量的增加，同步的耗时也会逐步增加，这对于用户来说是不太能够容忍的，那么我们有什么比较好的优化方式呢？比如从节点同步全部用异步的方式

全异步复制

当主节点执行完写操作时，通过全异步的方式通知从节点进行数据更新

• 缺点
  1. 如果主节点发生失败且不可恢复，那么所有尚未复制到从节点的写请求都会丢失，这样就会造成主节点写操作完成而从节点写操作丢失，从而导致数据不一致
• 优点
  1. 从节点数据不管多么落后，但是主节点总是能响应写请求，系统的吞吐性比较好
     

思考：虽然全异步的方式降低了延迟和提升了吞吐量,但是有可能会造成主从节点数据不一致，那么有没有一个折中一点的办法，既能提升吞吐量又能保证主从节点数据的一致性呢？

半同步复制

如果说全部从节点都一起同步数据不太实际，那么我们能不能只同步一个从节点，剩余的从节点采用异步的方式同步，这样子就能保证总是有两个节点拥有最新的数据，这种方式称为半同步

配置新的从节点

当我们希望增加新的从节点以提高容错能力，或者替换失败的副本，但是如何保证从节点和主节点的数据一致性。通常直接将一个从节点的数据文件复制到另一个从节点是不行的，因为主节点在不停的写数据，数据一直在变化，这种方式会导致不同的节点上出现不同时间点的数据。

停机增加从节点

通过停止主节点的写服务以保证数据不变，然后进行从节点数据迁移，但这样子就会导致写服务不可用，违反了高可用的设计目标

不停机、数据服务不中断增加从节点

1. 在某个时间点对主节点的数据副本产生一个一致性快照，这样避免长时间锁定整个数据库。目前大多数据库都支持此功能，快照也是系统备份所必需的。而在某些情况下，可能需要第三方工具，如mysql的innobackupex
2. 将此快照拷贝到新的从节点
3. 从节点连接到主节点并请求快照店之后所发生的数据更改日志。因为在第一步创建快照时，快照与系统复制日志的某个确定位置相关联。
4. 获得日志之后，从节点来应用这些快照点之后所有数据变更，这个过程称之为追赶。接下来，它可以继续处理主节点上新的数据变化。并重复1~4步骤。

处理宕机节点

在系统实际运行中，任何节点都有可能发生故障或者维护而导致中断甚至停机。目标是尽管个别节点会出现中断，但要保持系统总体的持续运行，并减小节点中断带来的影响。

从节点：追赶式恢复

从节点断线后重新恢复，根据副本的复制日志，从节点可以知道在发生故障之前所处理的最后一笔事务，然后连接到主节点，并请求自那笔事务之后中断期间内所有的数据变更。然后将这些数据变更应用到本地以更上主节点的数据。

主节点：节点切换

当主节点不可用时，通过选举切换

主从复制技术原理

基于语句复制

主节点记录所执行的每个写请求并将该操作语句作为日志发送给从节点。对于关系数据库，每个insert、update、delete语句转发给从节点，并且每个从节点都会执行分析这些sql语句

但是这种方式也有一些不适用的场景：

1. 任何调用非确定性函数的语句，如NOW()获取当前时间，或RAND()获取一些随机数等，会在副本上产生不同的结果
2. 如果语句ongoing使用了自增列，或者依赖与数据库的现有数据，则所有副本必须按照完全相同的顺序执行，否则可能会产生不同的结果。进而，如果有多个同时并发执行的事务时，会有很大的限制
3. 有副作用的语句(例如，触发器、存储过程、用户定义的函数等)，可能会在每个副本上产生不同的副作用

当然我们可以通过一些措施来解决这些问题，比如说将非确定性函数替换为执行之后的确定结果，这样所有的从节点直接使用相同的结果值。但是有太多的边界条件需要考虑，因为目前通常首选的是其它复制实现。MYSQL5.1之前采用的就是基于语句的复制，在默认情况下，如果语句中存在一些不确定性操作，则MYSQL会切换到基于行的复制。

基于预写日志(WAL)传输

通常每个写操作都是以追加的方式写到日志中

1. 对于日志结构存储引擎，日志是主要的存储方式。日志段在后台压缩并支持垃圾回收
2. 对于采用覆盖写磁盘的Btree结构，每次修改会预先写入日志，如果系统发生崩溃，通过索引更新的方式迅速恢复到此前一致状态

不管哪种情况，所有对数据库写入的字节序列都被记入日志。因此可以使用完全相同的日志在另一个节点上构建副本，除了将日志写入磁盘之外，主节点还可以通过网络将其发送给从节点。

缺点：

1. 日志描述结果非常底层，一个WAL包含了哪些磁盘块的哪些字节发生改变，诸如此类的细节，使得复制方案和存储引擎紧密耦合。如果数据库的存储格式从一个版本改为另一个版本，那么系统通常无法支持主从节点上运行不同版本的软件
2. 如果复制协议允许从节点的软件版本比主节点更新，则可以实现数据库软件的不停机升级，首先升级从节点，然后执行主节点切换，使升级后的从节点成为新的主节点。相反，复制协议如果要求版本必须严格一致（如WAL传输），那么就必须停机升级。

基于行的逻辑日志复制

还有一种复制方式是复制和存储引擎采用不同的日志格式，这样复制与存储逻辑剥离。这种复制日志称为逻辑日志，以区分物理存储引擎的数据表示

关系型数据库的逻辑日志通常是指一系列记录来描述数据表行级别的写请求：

1. 对于行插入，日志包含所有相关列的新值
2. 对于行删除，日志里有足够的信息来唯一标识已删除的行，通常是主键，但如果表上没有定义主键，就需要记录所有列的旧值
3. 对于行更新，日志包含足够的信息来唯一标识更新的行，以及所有列的新值(或至少包含所有已更新列的新值)

如果一条事务涉及多行的修改，则会产生多个这样的日志记录，并在后面跟着一条记录，指出该事务已经提交，MYSQL的二进制日志binlog使用该方式。

主从复制数据一致性问题

容忍节点故障只是使用复制其中的一个原因，还有比如可扩展性（采用多节点处理更多请求）和低延迟（将副本部署在地理上距离用户更近的地方）。主从复制要求所有写请求都经过主节点，任何从节点只能进行读请求，这样只需要增加从节点数量，就可以提高请求的服务的吞吐量，但是这种做法只适合异步复制，如果视图同步所有甲苯，则单个节点故障或者网络中断会造成整个系统无法写入，而且随着节点增加，程序的可靠性也会逐步降低。

如果一个用户正好从一个异步的从节点上读取数据，而该副本落后主节点，则应用会读到过期的信息。如果同时对主节点和从节点进行查询则会得到不一样的结果，这种不一致只是一个暂时的状态，如果停止写数据，经过一段时间后，从节点最终会赶上并与主节点保持一致。这种效应也称为最终一致性。

读已之写

正常情况，用户向应用提交数据后，通过向主库写入数据然后从从库读取数据，这种情况适用于数据变化比较少的情况，但是如果用户在写入数据后需要立马查看，如果数据未同步到从节点，可能导致用户看起来像数据丢失一样，这种情况下需要读写一致性。

• 如果一条数据只有自己可以修改，其它人不能修改，那么我们可以查自己数据的时候从主库查，读其他人数据的时候从从库读
• 如果一条数据可以被多个用户修改，那么上面的方法就行不通，我们可以跟踪上次更新的时间，在上次更新后的一分钟内，从主库读。

单调读

用户向应用提交数据后，在数据副本同步的过程中，用户发起一次查询请求，第一次从同步完成的副本中能够查出数据，第二次从还未同步完成的副本中查询导致数据没查到，为了防止这种情况，我们可以让用户每次总是从一个从节点中进行数据查询，这样就能保证虽然数据可能把不是最新的，但是也不会读到旧数据，这种比强一致性弱，比最终一致性强。