数据复制，即通过互联网网络在多台机器上保存相同数据的副本。目的为：使得数据在地理位置上更接近用户，从而降低访问延迟； 提高可用性； 多台机器同时提供数据访问服务，提高吞吐量
- 本章主要讨论三种流行的数据复制方法： 主从复制、多节点复制、无主节点复制
-
指定某一个节点为主节点，用户将请求发送给主节点，主节点写入成功后，发送给从节点。 用户可以在主节点或从节点进行查询，但是只有主节点提供写服务。
-
同步复制： 主节点等待从节点写入完成后，再返回客户端成功或失败
-
异步复制： 主节点发送消息给从节点后立刻返回客户端，不用等待从节点写入完成
-
同步复制优点： 保证从副本与主副本的数据一致性， 缺点：等待写入从节点会增加请求耗时; 如果从节点崩溃或者发生了网络故障，会导致写入失败
-
异步复制优点：无需等待从节点返回结果，可以提高主节点的吞吐性能。 缺点：从副本如果提供查询，会查到过期的数据
-
半同步： 一部分节点配置为同步复制，另一部分节点采用异步复制
-
配置新的从节点：
- 主副本生成快照，发送给新节点
- 新节点读取快照，同时读取快照生成的时间点，从主副本获取快照之后的数据
-
从节点失效：根据本地的变更日志和主副本进行对比，然后追赶主副本
-
主节点失效：需要确认主节点失效， 然后选举出主节点，并且使得整个系统认可新的主节点，具体参见一致性与共识与Raft一致性协议
- 基于语句的复制： 将主节点执行的修改操作的命令记录到日志文件中(如数据库中的INSERT、DELETE、UPDATE语句)
- 基于WAL的复制： 存储引擎在持久化的过程中会预写日志，和上一条的区别在于，WAL日志描述的数据结构非常底层，如果数据库的存储引擎进行了升级（从innodb升级到rocksdb），那么系统没有办法支持主从节点上运行不同版本的存储引擎
- 基于行的逻辑日志复制: 将数据库对每一行的修改添加删除记录下，例如mysql的binlog
-
如果有读请求发送了异步复制的副本节点，可能读到过期的信息，如果同时对主副本和从副本发起相同的查询，可能会得到不一致的结果。
-
读已提交： 用户发起写请求后，马上查询之前写请求提交的数据
- 如果用户在写入数据之后的读请求被发送到了异步复制的节点， 那么用户会发现刚刚提交的数据丢失了
- 解决方法：可能被修改的内容从主节点读取，其他内容从从节点读取；从节点监控主节点的更新状况与自己的滞后进度；客户端发送请求时带上时间戳，从副本保证复制进度超过请求的时间戳，不够则转发给更新的副本处理；
-
单调读： 一旦用户在某个副本上读到了某次写请求的数据，那么这次写请求必须对用户之后的所有读请求生效， 即不会发生回滚现象