美文网首页
ddia 第五章 复制

ddia 第五章 复制

作者: 寻找傅里叶 | 来源:发表于2021-08-20 15:08 被阅读0次

    复制的目的:

    • 高可用
    • 允许断网时继续工作
    • 低延迟
    • 高吞吐量

    由于数据会随着时间改变,流行的数据变更复制算法是个难题,流行的变更复制算法有下面三种:

    • 单领导
    • 多领导
    • 无领导

    单领导

    基于领导者的复制(主从复制):主库接受所有写操作,从库只接受读.主库发生变更时,将变更日志发送给所有的从库,从库根据日志更新数据.
    这种方式应用在PostgreSQL/MySQL等关系型数据库上,也用与MongoDB之类的非关系型数据库.

    同步复制与异步复制

    复制的过程采用同步还是异步也需要考量.
    同步复制时主库会等待从库的响应,可以保证从主库有一致的最新的数据.
    异步复制可以降低时延,但是不能保证数据持久化.
    部分同步,其他follower异步可以被称为半同步.通常情况下,基于领导者的复制都配置成为完全异步,并得到广泛使用.

    设置新从库

    有时为了增加副本数量或者替换失败节点,需要设置新从库.
    可以在某时刻获得主库的快照,避免锁定整个数据库,从库根据快照进行更新,并且拉取快照之后发生的数据变更进行处理.

    节点宕机

    从库失效: 追赶主库的数据变更进行恢复.
    主库失效: 需要提升从库作为主库,将客户端的请求发送至新的主库,其他从库也需要开始同步新主库(failover).通常有三个步骤:

    1. 确认主库失效
    2. 选举新主库
    3. 重新配置整个系统
      failover的问题:
    4. 异步复制时新主库数据落后于老主库,老主库重新上线后,数据冲突.解决方案:简单丢弃.但是如果与其他存储协调,比如redis,有可能导致数据不匹配.
    5. 脑裂:同时出现两个节点都以为自己是主库,都接收写操作,而没有冲突解决,那么数据可能丢失或者损坏.
    6. 确认主库失效的超时时间的设置.

    复制日志的影响

    基于语句(statement)的复制: 将所有写语句(insert, updatedelete)日志转发给每一个从库.
    缺点很明显:

    1. 调用诸如NOW等非确定性函数,可能在不同的从库产生不同的效果.
    2. 所有语句要按顺序执行
    3. 有副作用的语句可能在每个从库上带来的副作用不一样

    传输预写日志(WAL): 写操作通常追加到日志中,比如日志结构存储引擎(SSTableLSM)和使用B树.此时,日志是包含所有写入的追加字节序列.PG使用这种方式.
    缺点是: 记录的数据非常底层,包含磁盘中的字节更改.通常很难在主库和从库运行不同版本的数据库,影响到数据库的滚动升级.

    基于行(row)的复制: 逻辑日志复制,复制和存储引擎分离,使用不同的日志格式.例如,插入新行时,日志包含所有列的值;删除行时,标识该行已删除;更新行时,标识该行,以及新值.MySQL使用这种方式.这种方式易于解析,可以用来进行日志分析.

    基于触发器的复制: 允许用户自定义应用程序代码,在写入事务时,自动执行.它很灵活,但是也有更高的开销,更容易出错.

    复制延迟

    通常复制方案中,采用异步同步的方式.因此可能出现从库落后的情形.但是最终从库会赶上主库并且保持一致(最终一致性).

    多主复制

    多主情况,数据库副本可以分散在不同的数据中心,并且每个数据中心都有主库.数据中心内使用主从复制,数据中心之间,每个数据中心的主库都会将更改复制到其他数据中心的主库.
    与单节点主从复制方案相比,多主情况下每个写操作可以在本地数据中心处理,性能可能会更好.同时,每个数据中心是独立的,如果主库所在的数据中心发生故障,可以切换到其他数据中心.网络抖动也不会影响最终的写入.在离线的情况下,应用程序可以自身充当主库,这也是多主适用的场景.
    但是,需要面临不同数据中心修改相同数据的问题,即写冲突.

    处理写冲突

    以协同编辑为例,当两个用户同时进行更改时,每个用户的更改已经成功应用到本地主库,只在主库同步的时候才检测到冲突,此时冲突检测是异步的.方案可考虑的有:

    • 避免冲突,保证特定的操作都通过同一个主库,就不会发生冲突.
    • 实现冲突的合并解决,方案有只采纳特定的记录(比如最新的,但是会带来数据丢失),或者保留所有记录等待解决.可以在写入时,复制变更日志时检测冲突,调用应用层冲突处理逻辑;也可以在读取时,提示用户进行解决.

    拓扑结构

    常用的有:环形,星形和全部至全部形.
    环形和星形如果有节点出现故障,会影响其他节点之间复制日志的转发.
    全部至全部形可能出现复制日志被覆盖,可以利用版本向量来解决.

    无主节点复制

    这种复制模式放弃主节点,任何节点都可以接受来自客户端的请求(读和写).

    节点失效

    客户在写入的时候只要收到部分节点的响应,就可以认为写入成功,可以忽略某个节点失效的情形.
    但是当节点失效又重新上线时,如果用户请求该节点的数据,则有可能是过期的数据.因此,客户发送读请求时也是向多个副本并行发送请求,再利用相应的技术确定应该使用哪个值,并且对节点进行更新.
    节点失效重新上线后的数据追赶恢复,可以使用下面两种机制:

    • 读修复: 客户端读取时,通过多副本获得的值,判断该值过期,将新值写入副本.
    • 反熵过程: 后台进程不断查找副本之间的差异,将缺少的数据从一个副本复制到另一个副本.但是不能保证日志按照顺序复制写入,也有明显的同步滞后.

    读写quorum

    前面提到,客户写入时收到部分节点的响应,可以认为写入成功,那么部分节点是多少节点呢?
    通常如果有n个副本,写入需要w个节点确认,读必须要查询r个节点,只要w+r>n,就能保证读取的节点中一定包含最新值.wr分别就是写和读的quorum.
    与此对应的还有宽松的quorum,可以容忍偶尔读取旧值,对需要高可用和低延迟的场景来说,具有很高的吸引力.
    在网络中断的情况下,客户仍然能连接到某些节点,但是节点又不是能够满足仲裁的节点,此时允许采用宽松的仲裁方式:
    写入和读取仍然需要wr个成功的响应,但是包含并不在先前指定的n个节点,比如当前连接的是临时节点.当网络问题得到解决后,临时节点需要把接受到的写入全部发送到原始主节点上(数据回传).即只要集群中有任何w个节点可用,数据库就可以接受写入.也说明了即使满足w+r>n,也不能保证读取的值是最新的值.

    监控旧值

    基于领导者的复制中,数据库会公开复制滞后的度量标准,可以获得复制滞后量.
    然而在无主复制中,没有固定写入顺序,使得监控复制变得更加困难

    检测并发写入

    和多领导者复制类似,无主复制进行读修复和数据回传时也可能产生冲突.实现最终冲突解决,需要副本趋于相同的值:
    1.最后写入胜利(LWW,丢弃并发写入)的方式.但是此种方式可能会丢失部分数据,但在缓存中,是可以接受的.如果需要保证不丢失数据,只能确保每一个key只被写入一次,然后视为不可变.

    1. 利用版本向量捕捉操作之间的依赖关系,对每个key以及每个副本使用版本号.

    复制滞后的处理方式

    读自己的写

    出现复制延迟时,用户可能查看不到自己刚更新的内容.此时如需要保证读写一致性,可以有以下方案:

    • 从主库读取用户自己可能修改的内容,从从库读取其他用户的内容,适用于用户可能修改的内容较少,否则大部分读都落在主库上;
    • 可以跟踪上次更新的时间,如果时间较短,从主库读;或者监控从库的延迟,防止滞后比较久的查询落在从库;
    • 可以使用客户端记录时间戳,请求从库时,如果时间戳已经被从库记录,则可以返回查询.但是如果用户使用多设备终端,那么其他设备不知道时间戳,此种方案不合适,需要中心存储元数据.
      如果数据库分布在多个数据中心,用户的请求都需要路由到包含主库的数据中心.多设备情况下,很难保证不同设备会路由到同一数据中心.

    单调读

    如果每次查询的从库时延不一样,有可能出现每次查看的数据都不一样的情况.
    可以采用每次用户都读取同一个从库来保证单调读.

    一致前缀读

    如果数据写入不同的分区,那么全局的写入顺序无法得到保证.
    可以通过确保因果相关的写入都写入相同分区,以及采用跟踪因果依赖关系的算法解决.
    总结:明明是异步复制却假设复制是同步的,这是很多麻烦的根源。

    相关文章

      网友评论

          本文标题:ddia 第五章 复制

          本文链接:https://www.haomeiwen.com/subject/ktfvbltx.html