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