同步复制与异步复制

主从复制：其中一种设计，包括一个同步的从节点，和一个异步的从节点。

从节点2在接收复制日志之前有一段很长的延迟。通常情况下，复制速度会非常快，例如多数数据库系统可以在一秒之内完成所有从节点的更新。但是，系统其实并没有保证一定会在多长时间内完成复制。有些情况下，从节点可能落后主节点几分钟甚至更长时间，例如，由于从节点刚从故障中恢复，或者系统已经接近最大设计上限，或者节点之间的网络出现问题。

同步复制的优点是：一旦向用户确认，从节点可以明确保证完成了与主节点的更新同步，数据已经处于最新版本。万一主节点发生故障，总是可以在从节点继续访问最新数据。缺点则是：如果同步的从节点无法完成确认（例如：由于从节点发生崩溃，或者网络故障，或任何其他原因），写入就不能视为成功。主节点会阻塞其后所有的写操作，直到同步副本确认已完成。

因此，把所有从节点都配置为同步复制有些不切实际。因为这样子的话，任何一个同步节点的中断都会导致整个系统更新停滞不前。**实践中，如果数据库启用了同步复制，通常意味着其中某一个从节点是同步的，而其他节点这是异步模式。**万一同步的从节点变得不可用或性能下降，则将另一个异步的从节点提升为同步模式。这样可以保证至少有两个节点（即主节点和一个同步从节点）拥有最新的数据副本。这种配置有时候也叫做半同步。

主从复制还经常会被配置为全异步模式。此时如果主节点发生失败且不可恢复，则所有尚未复制到从节点的写请求都会丢失。这意味着即使向客户端确认了写操作，却无法保证数据的持久化。但是全异步配置的优点则是，不管从节点上数据多么滞后，主节点总是可以继续响应写请求，系统的吞吐性能更好、

异步模式这种弱化的持久性听起来是一个非常不靠谱的折中设计，但是异步复制还是被广泛使用，特别是那些从节点数量巨大或者分布于广域地理环境。我们常见的问题，会有复制滞后问题

配置新的从节点：
当如果出现以下情况下，如需要增加副本数以提高容错能力，或者替换失败的副本，就需要考虑增加新的从节点。但是如何确保新的从节点和主节点保持数据一致呢？

简单地将数据文件从一个节点复制到另一个节点通常是不够的，主要是因为客户端仍在不断得向数据库写入新数据，数据始终处于不断变化之中，因此常规的文件拷贝方式将会导致不同节点上呈现出不同时间点的数据，这不是我们所期待的。

或许应该考虑锁定数据库（使其不可写）来使磁盘上的文件保持一致，但是这会违反高可用的设计目标。好在我们可以做到在不停机，数据服务不中断的前提下完成从节点的设置。逻辑上的主要操作步骤如下：

1. 在某个时间点对主节点的数据副本产生一个一致性的快照。这样子避免长时间锁定整个数据库，炉前大多数数据库都支持此功能，快照也是系统备份锁必须的。而在某些情况下，可能需要第三方工具，入MYSQL的innobackupex
2. 将此快照拷贝到新的从节点
3. 从节点链接到主节点并请求快照点之后所发生的的数据更改日志；因为在第一步创建快照时候，快照与系统复制日志的某一个确定位置相关联，这个位置信息在不同的系统中有不同的称呼，
4. 获得日志之后，从节点来应用这些快找点之后所有数据变更，这个过程称之为追赶。接下来，他可以继续处理主节点上新的数据变化。并且重复步骤一~步骤4

从节点失效：追赶式恢复
主节点失效：节点切换

上述这些问题，包括节点失效，网络不可靠，副本一致性，持久性，可用性与延迟之间各种细微的权衡，实际上正是分布式系统核心的基本问题。

基于行的逻辑日志复制 mySql
另一种方法就是复制和存储引擎采用不同的日志格式，这样复制与存储逻辑剥离，这种复制日志称为逻辑日志，用来区分物理存储引擎的数据表示。

关系型数据库的逻辑日志通常是指一系列记录来描述数据表行级别的写请求：

1. 对于行插入，日志包含所有相关列的新值。
2. 对于行删除，日志里有足够的信息来唯一标识已经三处的行，通常是靠主键，但是如果表上没有定义
   主键，就需要记录所有列的旧值
   3.对于行更新，日志包含足够的信息来唯一表示更新的行，以及所有列的新值（或者至少包含所有已经更新列的新值）

如果一条事务设计多行的修改，则会产生多个这样的日志记录，并在后面跟着一条记录，指出该事务已经提交。Mysql的二进制日志binlog（当配置为基于行的复制时）使用该方式。

从节点最终会赶上并且与主节点保持一致，这种效应也被称为最终一致性。正常情况下，主节点和从节点上完成写操作之间的时间延迟（复制滞后）可能不足1秒，这样子的滞后，在实践中中通常不会导致太大的影响。但是，如果系统已经接近设计上线，或者网络存在问题，则滞后可能轻松增加到几秒甚至几分钟不等。

离线客户端操作：
另一种多主复制比较适合的场景是：应用在于网络断开后还需要继续工作。