复制的难点在于处理复制数据的变更
复制时的权衡:使用同步复制还是异步复制?如何处理失败的副本?
领导者与追随者
多副本问题:如何确保数据都落在了所有副本上--基于领导者的复制(主从复制)
主从复制原理
- 领导者将新数据写入本地存储时,会将数据变更发送给所有追随者,称为复制日志或变更流
- 每个追随者从领导者拉取日志,并相应更新其他数据库副本,按照领导者处理的相同顺序应用所有写入
- 写数据:领导者;读数据:领导者或追随者
热备:能接受客户端读请求的副本
温备:追随领导者,不处理客户端的任何查询
同步复制与异步复制
同步复制的速度:从库可能落后主库几分钟或更久,例如:从库正在从故障中恢复,系统在最大容量附近运行,或者节点之间存在网络问题
- 同步复制优点:从库保证有与主库一致的最新数据副本
- 同步复制缺点:如果从库没有响应,主库无法处理写入操作。主库必须组织所有写入,等待从库再次可用
半同步:一个主库与从库同步,其他从库异步。保证至少两个节点拥有最新的数据副本
主从同步:完全异步,但写入不能保证持久,因为主库同步从库前可能发生主库宕机。【链式复制:同步复制的变体,可以解决】
设置新从库
- 获取主库的快照
- 将快照复制到新从库节点
- 从库连接到主库,并拉去快照后的所有数据变更。要求快照与主库复制日志中的位置精确关联,比如MySQL中的binlog
- 从库处理完快照之后积压的数据变更,可以继续处理主库产生的数据变化了
处理节点宕机
目标:即使个别节点失效,也能保持整个系统运行
- 从库失效:从库恢复后,从日志中获得发生故障前最后一个事务,连接到主库,请求从从库断开连接时发生的所有数据变更
- 主库失效:故障切换
复制日志的实现
基于语句的复制
主库记录下它执行的每个写入请求(语句(statement))并将该语句日志发送给其从库。
存在问题:
- 任何调用 非确定性函数(nondeterministic) 的语句,可能会在每个副本上生成不同的值。比如 NOW(), RAND()
- 如果语句使用了自增列(auto increment),或者依赖于数据库中的现有数据(例如,UPDATE ... WHERE <某些条件>),则必须在每个副本上按照完全相同的顺序执行它们,否则可能会产生不同的效果。影响并发
- 有副作用的语句(例如,触发器,存储过程,用户定义的函数)可能会在每个副本上产生不同的副作用,除非副作用是绝对确定的
传输预写式日志WAL
对于覆写单个磁盘块的B树,每次修改都会先写入 预写式日志(Write Ahead Log, WAL),以便崩溃后索引可以恢复到一个一致的状态
- 日志都是包含所有数据库写入的仅追加字节序列。可以使用完全相同的日志在另一个节点上构建副本:除了将日志写入磁盘之外,主库还可以通过网络将其发送给其从库
- 当从库应用这个日志时,它会建立和主库一模一样数据结构的副本
- 日志记录的数据非常底层,因此主从库需要运行相同版本的数据库软件
- 运维时如果升级软件版本,有可能会要求停机
逻辑日志复制(基于行)
复制和存储引擎使用不同的日志格式,复制日志被称为逻辑日志,以将其与存储引擎的(物理)数据表示区分开来
- 关系型数据库通常以行作为粒度描述数据库写入的记录序列
- 对于插入的行,日志包含所有列的新值
- 对于删除的行,日志包含足够的信息来唯一标识已删除的行。通常是主键,或者所有列的旧值
- 对于更新的行,日志包含足够的信息来唯一标识更新的行,以及所有列(至少是更新列)的新值
- 修改多行,会生成多个这样的记录,后面跟着事务已提交的记录--MySQL使用此方法
- 优点
- 逻辑日志与存储引擎分离,方便向后兼容。可以让领导者和跟随者运行不同版本的数据库软件
- 对于外部应用,逻辑日志也更容易解析。比如复制到数据仓库,或者自定义索引和缓存。被称为数据变更捕获
基于触发器的复制
复制延迟问题
- 异步复制时,如果从库落后,并提供了读,可能导致同时对主从库执行查询,得到不同结果
- 异步复制特性:最终一致性
读己之写一致性
用户在提交数据后,总会看到自己提交的任何更新,其他用户可能稍后看到。保证用户自己的输入被正确保存
- 写后读,走主库,比如主库读取自己档案,从库读取其他用户档案
- 如果应用中大部分内容被用户编辑,上述方案无效。可以指定更新后的时间窗口,比如上次更新的一分钟内从主库读。
- 客户端记录最近一次写入的时间戳,从库提供查询时,保证该时间戳前的变更都已经传播到了本从库;否则从另外的从库读,或者等待从库追赶上来
- 如果副本在多个数据中心,比较复杂。任何需要从领导者提供服务的请求,都必须路由到包含主库的数据中心。
用户跨设备同时发出请求,情况更为复杂
- 记录更新时间戳变得更困难。元数据需要一个中心存储
- 不同设备可能路由到不同的数据中心。如果你的方法需要读主库,就需要把同一用户的请求路由到同一个数据中心
单调读
时光倒流:用户顺序进行多次读取,路由到了进度不同的从库。先看到的数据突然消失
- 单调读:确保同一用户总是从同一副本读,可以通过对用户ID哈希的方式进行路由
一致性前缀读
分区/分片数据库问题:不同分区之间独立,不存在全局写入顺序。可能出现一系列事件前后顺序不一致问题(用户从从库中读取数据时,可能看到数据库某些部分处于就状态,某些处于新状态)。比如回答可能在提问前发生
- 一致性前缀读:任何因果相关的写入都写入相同分区
多主复制
- 基于领导者复制的主要缺点:只有一个主库,所有的写入都要通过它
- 多个领导者的复制:允许多个节点接受写入,复制仍然是转发给所有其他节点。每个领导者也是其他领导者的追随者
多主复制应用场景
运维多个数据中心
基于领导者的复制设置,主库必须位于其中一个数据中心,且所有写入都必须经过该数据中心
多领导者配置中可以在每个数据中心都有主库。每个数据中心内使用常规主从复制;数据中间,每个数据中心的主库都会将其更改复制到其他数据中心的主库
运维多个数据中心时,单主和多主的比较
性能
- 单主配置:每个写入都得穿过互联网,进入主库所在的数据中心。会增大写入时间
- 多主配置每个写操作都可以在本地数据中心进行处理,与其他数据中心异步复制。感觉到性能更好。
容忍数据中心停机
- 单主配置:如果主库所在的数据中心发生故障,必须让另一个数据中心的追随者成为主领导者
- 多主配置:每个数据中心都可以独立于其他数据中心继续运行。若发生故障的数据中心归队,复制会自动赶上
容忍网络问题
- 单主配置:单主配置对网络连接问题非常敏感,因为写是同步的,数据中心之间网络不如数据中心内的本地网络可靠
- 多主配置:异步复制的多主配置更好地承受网络问题
多主复制缺点:两个数据中心可能修改相同内容,写冲突必须避免
需要离线操作的客户端
例如手机、笔记本的日历等,无论是否联网,都需要随时能查看会议,并且如果在离线情况下做任何更改,设备上线时需要与服务器和其他设备同步
- 每个设备都有一个充当领导者的本地数据库(接受写请求),在所有设备的日历副本之间同步时,存在异步的多主复制过程,复制延迟取决于何时访问互联网
- 相当于每个设备都是一个数据中心
协同编辑
- 一个用户编辑文档时,所做的更改将立即应用到其他副本,并异步复制到服务器和编辑同一文档的任何其他用户
- 如果想要不发生编辑冲突,则应用程序需要先将文档锁定,然后用户才能进行编辑;如果另一用户想编辑,必须等待第一个用户提交修改并释放锁定。这种协作模式相当于主从复制模型下在主节点上执行事务操作
- 为了加速写作,可编辑的粒度需要非常小(例如单个按键,甚至全程无锁)
处理些写入冲突
多主复制最大的问题:写冲突
同步与异步冲突检测
- 单主数据库:第二个写入被阻塞,等第一个写入完成,或被终止
- 多主复制:两个写入都成功,稍后的时间点仅仅异步检测到冲突
- 如果想冲突检测同步-即等待写入被复制到所有副本,然后再告诉用户写入成功,但是这失去了多主复制优势
避免冲突
- 避免冲突:应用程序确保特定记录的所有写入都通过同一个领导者
- 但是如果数据中心故障,需要把流量重新路由,就会导致冲突避免会中断,必须处理不同主库同时写入的可能性
收敛至一致的状态
- 最后写入胜利LWW:给每个写入一个唯一的ID,挑选最高ID的写入作为胜利者,并丢弃其他写入,但容易导致数据丢失
- 以某种方式将值合并在一起:例如,按字母顺序排序,然后连接,上图得到的结果可能是B/C
- 在保留所有信息的显示数据结构中记录冲突,并编写解决冲突的应用程序代码(也许通过提示用户的方式)。
自定义冲突解决逻辑
写时执行
数据库检测到复制更改日志中存在冲突,调用冲突处理程序
读时执行
检测到冲突时,所有冲突写入被存储。下次读取数据时,会将多个版本的数据返回给应用程序。应用程序可能提示用户或自动解决冲突,并将结果写回数据库
- 冲突解决适用于单个行或文档层面,而不是整个事务。如果有一个事务会原子性的进行几次不同的写入,则对于冲突解决而言,每个写入仍需分开单独考虑
多主复制拓扑
- 复制拓扑:描述谢图从一个节点传播到另一个节点的通信路径
- 两个以上的领导者,拓扑很多样,其中MySQL仅支持环形拓扑
- 防止无限复制循环:因为圆形和星型拓扑,节点需要转发从其他节点收到的数据更改。每个节点都有唯一的标识符,在复制日志中,每个写入都标记了所有已经过的节点的标识符
- 多主拓扑结构的问题:
- 一个节点故障,可能中断其他节点之间的复制消息流
- 拓扑结构可以重新配置,但需要手动操作
- 全部到全部的容错性更好,避免单点故障,但可能因为网络问题导致消息顺序错乱--通过版本向量技术解决
无主复制
无主复制:客户端直接写入到几个副本中;或者协调者节点代表客户端进行写入,但协调者不执行特定的写入顺序
节点故障时写入数据库
无助复制时,如果节点发生故障,客户端的写请求并行发送给所有副本,节点故障的副本错过写入,在后续恢复之后客户端的读请求,可能将旧值作为响应--通过将读请求并行发送到多个节点解决,版本号用于确定哪个值更新
读修复和反熵
故障节点重新联机后,如果赶上它错过的写入?
读修复
客户端并行读取多个节点时,可以检测到旧值,将新值写回,适合读多场景
反熵过程
一些数据库存储具有后台进程,该进程不断查找副本之间的数据差异,将任何缺少的数据从一个副本复制到另一个副本,但复制可能存在显著延迟
读写的法定人数
假定有n个读本,每个写入必须有w个节点确认才能被认为是成功的,并且必须至少为每个读取查询r个节点
- 只要\(w + r > n\),就可以在读取时获取最新的值
- w值的读写称为法定人数的读写
- 常见选择使n为奇数(通常为3或5),并设置\(w = r = (n - 1) / 2\)(向上取整)
- 根据需要更改,例如\(w = n\) 和\(r = 1\)就是和读多写少场景,这样读速度更快,但是会一个失败节点导致所有数据写入失败
仲裁条件\(w + r > n\)允许系统容忍不可用的节点
- 如果\(w <n\),如果节点不可用,我们仍然可以处理写入
- 如果\(r <n\),如果节点不可用,我们仍然可以处理读取
- 对于\(n = 3,w = 2,r = 2\),我们可以容忍一个不可用的节点
- 对于\(n = 5,w = 3,r = 3\),我们可以容忍两个不可用的节点
- 通常,读取和写入操作始终并行发送到所有n个副本。 参数w和r决定我们等待多少个节点,即在我们认为读或写成功之前,有多少个节点需要报告成功
仲裁一致性的局限性
但是,即使在 \(w + r> n\) 的情况下,也可能存在返回陈旧值的边缘情况。
- 如果使用了宽松的法定人数,w 个写入和 r 个读取落在完全不同的节点上,r节点和w节点之间不再保证有重叠节点
- 两个写入同时发生,不清楚哪一个先发生
- 写操作和读操作同时发生,写操作可能仅反映在某些副本上。通过合并并发写入,如果根据时间戳选出胜利者,则由于时钟偏差可能导致写入丢失
- 读写同时发生,写操作可能仅反应在某些副本,这时读取结果不确定是旧值还是新值
- 写操作在某些副本上成功,而在其他节点上失败,在小于w个副本上写入成功,整体写失败,但是写成功的副本没有回滚,后续读可能读取到这次失败的值
- 如果携带新值的节点失败,需要读取其他带有旧值的副本,并且其数据从带有旧值得副本中恢复,存储新值得副本数低于w,打破法定人数条件
- 即使一切工作正常,有时也会不幸地出现关于时序(timing) 的边缘情况
不要把 w 和 r 当做绝对的保证,应该看做是概率。
强有力的保证需要事务和共识
监控陈旧度
- 基于领导者的复制,数据库会公开复制滞后得度量标准,可以做监控
- 无领导复制中,没有固定的写入顺序,监控困难
宽松法定人数与提示移交
- 问题:网络中断导致剩余可用节点可能少于w或r,客户端达不到法定人数
- 权衡
- 对于所有无法打到w或r节点法定人数的请求,是否返回错误是更好的?
- 或者是否应该接受写入,然后将它们写入一些可达的节点,但不在这些值通常所存在的n个节点上--宽松的法定人数
- 大型集群中,节点数量明显多于n个,写和读仍然需要w和r个成功的响应,但是不来自指定的n个节点
- 提示移交:网络中断得到解决时,另一个节点临时接收的一个节点的任何写入都被发送到适当的“主”节点
优点:提高了写入可用性:任何w个节点可用,数据库就可以接受写入
缺点:即使当\(w + r> n\)时,也不能确定读取某个键的最新值,因为最新的值可能已经临时写入了n之外的某些节点
运维多个数据中心
- 无助复制也适用于多数据中心操作,因为它旨在容忍冲突的并发写入,网络中断和延迟尖峰
- 无论数据中心如何,每个来自客户端的写入都会发送到所有副本,但客户端通常只等待来自其本地数据中心内的法定节点的确认,从而不会受到跨数据中心链路延迟和中断的影响
- 对其他数据中心的高延迟写入通常被配置为异步发生,尽管配置有一定的灵活性
检测并发写入
- 无主复制,允许多个客户端同时写入相同的key,会冲突
- 读修改和提示移交期间可能也发生冲突
最后写入胜利(丢弃并发写入)
- 方法:最后写入胜利
- 优点:实现了最终收敛的目标
- 缺点:以持久性为代价,会丢失数据,甚至可能会删除不是并发的写入
- 使用场景:唯一安全的方法,即每一个键只写入一次,然后视为不变,避免并发更新
“此前发生”的关系和并发
- 需要一个算法知道两个操作是否并发,如果一个操作再另一个操作之前,后操作直接覆盖早操作,如果是并发的需要解决冲突
捕获“此前发生”关系
服务器可以通过查看版本号来确定两个操作是否并发的,算法原理
- 服务器为美俄key保留一个版本号,每次写入key时都增加版本号,并将新版本号与写入的值一起存储
- 当客户端读取key时,服务器将返回所有未覆盖的值以及最新的版本号,客户端在写入前必须读取
- 客户端在写入Key时,必须包含之前读取的版本号,并且必须将之前读取的所有值合并在一起。(针对写入请求的响应可以像读取请求一样,返回所有当前值,这使得我们可以像购物车示例那样将多个写入串联起来)
- 当服务器接收到具有特定版本号的写入时,可以覆盖该版本号或更低版本的所有值,但是必须用最高的版本号来保存所有的值
当一个写入包含前一次读取的版本号时,会告诉我们的写入是基于之前的哪一种状态
合并同时写入的值
- 优点:没有数据被无声的丢弃
- 缺点:客户端需要额外的工作
- 合并并发值问题:当多个操作并发发生,客户端需合并并发写入的值(称其为兄弟值),简单按版本号或时间戳选择一个值会丢失数据,以购物车为例可采用集合求并等更合理方法,但涉及删除操作时需用 “墓碑” 标记已删除项目,还可利用如 Riak 的数据类型支持的 CRDT 等数据结构自动合并兄弟值。
版本向量
- 版本向量概念:在有多个副本但无领导者时,除对每个键使用版本号外,每个副本处理写入时增加自己的版本号并跟踪其他副本的版本号,所有副本的版本号集合称为版本向量
- 版本向量作用:版本向量从数据库副本发送到客户端再发回数据库,可区分覆盖写入和并发写入,确保从一个副本读取并写回到另一个副本时安全,虽可能产生兄弟值,但正确合并就不会丢失数据。
- 与矢量时钟关系:版本向量有时也被称为矢量时钟,虽不完全相同,但在比较副本状态时,版本向量是正确的数据结构。