是Leader，这种情况被称为脑裂。此时两个Leader都会接受写请求，数据很可能会出现丢失或损坏。
什么时候进行故障切换也是一个值得探讨的问题：较长的超时时间意味着在Leader失效的情况下恢复时间更长。然而，如果时间太短，可能会有不必要的故障转移。例如，临时负载高峰时刻可能导致节点的响应时间增加到超时，那么不必要的故障转移会使情况变得更糟，而不是更好。为此，一些运营团队更愿意执行手动的故障转移，即使系统本身支持自动的故障转移。
3. 日志的复制
日志在副本的一致性之中是至关重要的，所以我们接下来简要的梳理一下日志复制可用的方法：
- Statement-Based复制
在最简单的情况下，Leader将每个写请求通过日志的形式发送给Follower。每个Follower解析和执行对应的操作语句，虽然这听起来很合理，但是实际操作中会存在一些坑：
(1) 非确定性函数，如now()获得当前的日期和时间或rand()得到一个随机数，这样会导致副本之间的不一致。（这里可以转换思维，用一个确定的修改值，来替换不确定性的函数调用)
(2) 如果使用一个自动递增的列，或如果他们依赖于数据库中的现有数据（例如，更新…在<条件>），他们必须执行完全相同的顺序在每个副本，否则也会产生不一致性。（异步转发，乱序到达。这个可以通过操作序列号等强制要求进行规避。）
(3) 有副作用的语句（例如触发器、存储过程、用户定义函数）可能会导致每个副本上出现不同的副作用。
Write-ahead日志复制
日志是一个只包含所有写入操作的字节序列。我们可以使用完全相同的日志来在另一个节点上构建一个副本。Leader将日志写入磁盘之后，将它通过网络发送给Follower。当Follower处理这个日志时，它构建了一个与Leader完全相同的数据结构的副本。这种方式的缺点是：日志在非常低的级别上描述数据。这使得数据拷贝与存储引擎紧密耦合。
Row-based日志复制
Row-based与Write-ahead的方法类似，但是它允许复制日志与存储引擎内部分离。这种日志称为逻辑日志，逻辑日志通常是描述在一个行的粒度上记录写入操作：
对于插入的行，日志包含所有列的新值。
对于已删除的行，日志包含足够的信息以唯一地标识删除的行。（主键）
对于更新的行，日志包含足够的信息以唯一地标识更新的行，以及所有列的新值。
由于逻辑日志与存储引擎内部分离，因此可以更容易地保持向后兼容，从而允许Leader与Follower运行不同版本的数据系统，甚至是不同的存储引擎。同时，逻辑日志格式对外部应用程序也更容易解析。可以将逻辑日志的内容发送到外部系统（如用于离线分析的数据仓库），或者用于构建自定义索引和缓存。
4. 复制延迟
副本可以增加系统的可伸缩性（处理比单个机器处理更多的请求）和降低延迟（将副本放置在离用户更近的地方）。写入操作必须通过Leader副本，但是只读查询可以在任何副本上进行。 对于一次写入，多次读取的应用来说，采用读扩展架构是十分合理的。但是由于上文提及的原因，我们通常不会采用同步复制的方式。这将导致数据出现明显的不一致性：如果您同时对Leader和Follwer执行相同的查询，可能会得到不同的结果，因为并不是所有的写入实时在Follower上反馈。这种不一致性仅仅是暂时状态，所以这种情况被称为最终一致性。
对于这种情况我们应该这么去处理和理解，我们下回分解～～～（第五章的内容炒鸡多，接下来会通过多篇读书笔记来给大家梳理，讲解，下一篇再见～～）