复制的重要可选项:
关系型DB 中,这通常是个可配置项,而其他系统通常是硬性指定或只能二选一。
如图-1案例,网站用户更新个人头像图片的流程:
图-2显示了系统各模块间通信情况。请求或响应标记为粗箭头。
图-2中:
从节点2接收复制日志前存在一段长延迟。复制一般速度很快,大多DB系统能在1s内完成所有从节点更新。但并不保证复制耗时多久。有时,从节点可能落后主节点几min或更久,如从节点正在故障恢复或系统已接近最大设计上限或节点间存在的网络问题。
同步复制的
因此,将所有从节点都设置为同步复制不切实际:任一同步节点的中断都会导致整个系统更新停滞。实践时,若DB启用同步复制,意味着其中某一从节点是同步的,而其他节点是异步模式。一旦同步的从节点不可用或性能降低,则将另一个异步的从节点提升为同步模式。这就保证至少有2个节点(主节点和一个同步从节点)拥有最新的数据副本。 这种配置有时也称为半同步(semi-synchronous)。
主从复制经常会被配置为全异步模式。 此时若主节点失效且不可恢复,则任何尚未复制到从节点的写请求都会丢失。那么,即使已向客户端确认成功,写入也不能保证数据的持久化。但全异步的优点是:不管从节点数据多么滞后,主节点也能总是继续响应写请求,系统吞吐量极高。
异步模式这种弱化的持久性听起来是个很不靠谱的trade off,但异步复制还是被广泛使用,尤其是从节点数量巨大或分布地理环境较广。
复制问题研究 异步复制系统,在主节点故障时可能丢数据。这是个严重问题,因此在保证不丢数据前提下,人们尝试各种方案提高复制性能和系统可用性。 如链式复制是同步复制的一种变体,已在一些系统(如Microsoft Azure存储)实现。 多副本一致性与共识之间密切联系(即让多个节点对数据状态达成一致)。本文主要专注于数据库实践中常用的、相对简单的复制技术方案。