优点：简单 缺点：语句副作用，或者随时间改变返回值的函数的使用会导致复制的数据产生改变。
优点：解决基于语句复制的问题。 缺点：日志描述过于底层：哪些磁盘块的哪些字节发生了改变，和引擎实现高度耦合，不利于模式演进。
用一系列记录来描述数据表行级别的写请求：
MySQL binlog 基于此模式。
优点：更利于模式演进，支持向后兼容，同时解耦特性引擎便于外部解析。
触发器支持注册自己的应用层代码并在数据发生改变时被调用。
优点：将复制控制交给应用层，支持更高的灵活性。 缺点：开销更大，更容易出错。
主节点与从节点 复制 单个节点可以完整存放所有数据副本，节点间进行主从复制。 配置新从节点 可以通过快照来加速新从节点复制： 对主节点的数据副本产生一个一致性快照，避免长时间锁定数据库。 拷贝快照到从节点 请求快照后面的更改日志 应用数据变更 节点失效 从节点失效：追赶式恢复 主节点失效：节点切换 自动切换 确认失效 选举新的主节点 使主节点生效 挑战 从节点复制不完整 各个数据层数据不一致，如 MySQL 和 Redis 之间 多个主节点选举：脑裂 如何有效检测主节点失效 复制日志实现 复制滞后问题 多主节点复制 使用场景 多数据中心 优点： 性能 容忍数据中心失效 容忍网络问题 缺点：写冲突 离线客户端操作 协作编辑 处理写冲突 同步与异步冲突检测 同步：等待写请求完成对所有主节点的同步再通知用户写入成功。 异步：等待单一主节点写入成功后通知用户卸乳成功，稍后多主节点数据同步的时候才能检测到冲突 避免冲突 收敛于一致的状态 自定义冲突解决逻辑 写入时解决 读取时解决 拓扑结构 环形拓扑 星型拓扑 全部-至-全部型拓扑 无主节点复制