PacificA:基于日志复制的分布式存储技术论文

1   概要介绍

复制协议是一个实用复制机制的关键，简单性和模块化是构建实用系统的关键因素。本文的复制框架包含了以下特性：

（1）复制组配置管理与数据复制分离，Paxos用于管理配置，主/备模式用于数据复制。

（2）分散监控用来检测故障并触发重新配置，监控流量遵循数据复制的通信模式。

（3）通用的抽象模型，该模型澄清了正确性并允许不同设计实例。

本文描述的基于日志的分布式系统和以前的系统（如Boxwood和Bigtable）使用的新复制方案进行对比。本文描述的方案在简单性方面具有优势，因为不依赖单独的锁服务，并且由于更好的数据共享而减少了网络流量。

本文组织如下：

第2节介绍了我们提出的复制框架。第3节介绍了将该框架应用于一般基于日志的存储系统的不同方法。第4节重点对PacificA的复制方案实施和评估。

 

2   PACIFICA复制框架

在集群环境中服务器可能会出现故障。服务器可能出现故障，消息也丢失或者乱序，也可能发生网络分区，服务器上的时钟不一定是同步的。容错是系统的首要任务，通用的做法是系统维护一组数据，每组数据互为备份，每段数据都在一组服务器上复制，称为副本组。副本组中的每个服务器都充当一个副本。一台服务器可以作为多个组中的副本。副本之间的数据备份协议遵循主备模式。

副本组中的一个副本被指定为主副本，而其他副本被称为备份副本。副本组的组成（它指示谁是主副本，谁是备份副本）称为副本组的配置。副本组的配置因副本失败或添加而更改，版本信息用于记录此类更改。

本文实现的是强一致性的复制协议，因为它代表了最自然的一致性模型。因为强一致性确保复制系统的行为与非复制系统的行为相同。

弱一致性模型通常会增加构建在复制层之上程序的复杂性。在第2.7小节中，我们将讨论强一致性的一种弱化方法。

2.1主/备模式数据复制

我们采用主/备份模式进行数据复制。我们区分两种类型的客户机请求：不修改数据的查询和修改数据的更新。在主/备模式中，所有请求都被发送到主服务器。主节点在本地处理所有查询，并在处理更新时同步到所有备份对象。由于几个原因，主/备模式在实践中很有吸引力。它很简单，非常类似于非复制的情况，主服务器作为唯一的访问点。查询往往在许多工作负载中占主导地位，直接在单个服务器上处理。

如果一个副本组中的所有服务器以相同的顺序处理同一组请求，则可以实现强一致性。因此，主节点为更新分配连续且单调递增的序列号，并通知所有备份节点按此顺序连续处理请求。为了描述方便，我们将副本建模为一个准备请求列表和一个指向该列表的提交点。该列表是根据分配给请求的序列号排序的，并且是连续，准备列表上直到提交点为止的的prefix称为提交列表。

主服务器上的应用程序状态是将提交列表中的所有请求按初始状态上序号的递增顺序应用的结果。只要系统没有遇到它无法容忍的故障（例如，当前配置中所有副本的永久性故障），就可以保证提交列表上的请求不会丢失。

正常情况查询和更新协议：在正常情况下（即没有重新配置），数据复制协议很简单。当主服务器接收到查询时，它会根据当前提交的列表所表示的状态处理查询，并立即返回响应。

对于更新：主节点为请求分配下一个可用的序列号。然后将请求连同其配置版本和序列号一起发送到所有备份副本。备份副本在接收到准备消息时按序列号的顺序将请求插入到其准备列表中。然后给主服务器发送一个确认消息。当主服务器接收到来自所有备份副本的确认时，将提交请求，即主服务器将其提交点前移到最高点，以便提交到该点的所有请求。然后主副本向客户机发送确认消息，指示成功完成。对于每个prepare消息，主服务器会进一步在已提交的点上附带序列号通知备份副本服务器已提交的所有请求。

因为主服务器只在所有副本将请求插入其准备列表后才将请求添加到其已提交列表中（向前移动提交点时），主服务器上的已提交列表始终是任何备份副本上已准备列表的prefix。另外，因为备份服务器只在主服务器完成后才将请求添加到其提交列表中，所以备份服务器上的提交列表被保证是主服务器上的提交列表的前缀。

主/备份协议仅在副本组的配置没有更改时才起作用。本系统的复制框架将配置管理与数据管理分开。

2.2配置管理

全局配置管理器负责维护系统中所有副本组的配置。configuration manager维护当前每个副本组的配置及其版本。

                    

当服务器检测（通过故障检测）副本有故障时，它可以启动重新配置；重新配置将从配置中删除有故障的副本。服务器还可以建议向配置中添加新的副本；例如，恢复所需的冗余级别。在这两种情况下，服务器都会将建议的新配置及其当前配置版本一起发送到configuration manager。只有当版本信息与configuration manager上当前配置的版本匹配时，才会接受请求，建议的新配置被通过，并且更新版本信息。否则，请求将被拒绝。

在主设备与备份设备的出现网络分区的情况下，可能会出现冲突的重新配置请求：主服务器可能希望删除一些备份设备，而一些备份设备试图删除主要设备。因为所有这些请求都基于当前配置，所以配置管理器接受的第一个请求将获胜。所有其他冲突请求都将被拒绝，因为configuration manager已升级到具有更高版本的新配置。

主副本唯一：在任何时候，只有当配置管理器在其维护的当前配置中将p作为主服务器时，服务器p才会认为自己是主服务器。因此，在任何时候，最多存在一个服务器，它将自己视为副本组的主服务器。

上图中，在旧配置中，A是主配置。在新配置中，旧的备份节点B将升级为新的主B，并从配置中删除A。第一行显示基于列表中最高序列号的已准备列表和已提交副本列表的状态。第二行显示对帐后的相应状态。

2.3租约和故障检测

配置管理器并不能保证任意时刻主服务器唯一，先看一种情况：网络分区时旧主节点和新主节点同时处理查询，而旧主节点可能不知道重新配置创建了新的主节点并将其从配置中删除。因为新的主节点可能已经处理了新的更新，所以旧的主节点可能正在处理过时状态的查询，从而违反了强一致性。      

我们的解决方案是使用租约。主节点通过定期向备份节点发送心跳并等待确认，从每个备份节点获取租约。如果从上次确认的心跳发送时间起已过指定的租约期，则主服务器认为其租约已过期。当备份服务器的任何租约过期时，主服务器不再将自己视为主服务器，并停止处理查询或更新。在这种情况下，主服务器将与配置管理器联系从当前副本配置中删除备份服务器。

只要发送方仍然是当前配置中的主节点，备份节点就会确认心跳。如果自上次从主服务器接收到心跳后已过宽限期，则备份服务器将认为对主服务器的租约已过期，并将联系配置管理器删除当前主节点并申请自己成为新的主节点。

假设时钟漂移为零，只要宽限期与租约期相同或更长，就可以保证租约在主服务器上比在备份服务器上过期早。备份服务器建议进行配置更改，以便在其对旧主服务器的租约到期时尝试担任主服务器的角色。因此可以保证在新的主成立之前，旧的主已经辞职；

类似的故障检测机制也用于其他系统，如GFS、Boxwood和Bigtable/Chubby。本系统和这些系统的一个关键区别是租约是从一个集群中获得。在例子中，用于故障检测的监控流量总是在两个需要彼此通信以进行数据处理的服务器之间：主服务器在处理更新时与备份服务器通信；心跳和确认也在主服务器和备份服务器之间。此外，当通信信道繁忙时，数据处理消息本身可以充当心跳和确认。实际的心跳和确认只在通信信道空闲时发送，从而最小化了故障检测的开销。此外，这种分散的实现也消除了负载和对某一固定服务器的依赖。每个服务器之间定期交换心跳和确认信息，因此负载可能非常大但是检测的时间间隔必须要小，以允许快速故障检测。在集中式解决方案中，由于集中式的服务器不可用（例如，由于网络分区）可能导致整个系统不可用，因为所有的主节点在失去中心服务器的租约时都必须退出

2.4重新配置、调节和恢复

复制协议的复杂性在于它如何处理重新配置。我们将重构分为三种类型：移除备份对象、移除主对象和添加备份对象。

备份副本的移除：当主服务器怀疑备份设备副本发生故障时，将触发删除一个或多个备份设备。主配置建议一个新的配置，该配置排除了那些可疑的备份设备。

主设备更换：当备份服务器怀疑主服务器使用前面描述的租用机制失败时，将触发对主服务器的删除。备份服务器提出一个新的配置，它本身就是新的主服务器，而旧的主服务器则被排除在外。批准后，备份的p将自己视为新的主，只有在和其他副本完成对账过程后才开始处理新的请求。在对帐期间，p为将准备列表中未提交的请求发送prepare消息，并将它们提交到新副本配置中。设Sn是p的提交点对应的序列号，p指示所有副本截断它们的准备列表，并且只保留序列号为Sn的所有请求。即使在对帐期间，如果新配置中的任何副本失败，也可以触发另一个重新配置。

因为备份服务器上的准备列表总是包含所有已提交的请求，因此通过提交准备列表中的所有请求可确保副本组之间数据一致。另外它还确保分配给任何已提交请求的序列号将被保留，并且即使在主要更改的情况下也不会重新分配。相反，准备列表中未提交部分中的请求不一定是必需的。例如，当主服务器分配序列号失败时，只要序列号尚未分配给已提交的请求，新的主节点可以将相同的序列号分配给不同的请求。

增加新的备份设备：可以将新副本添加到副本组中，以在组中的副本出现故障后恢复冗余级别。在新复制副本在加入副本组之前具有正确的准备列表。新复制副本获取正确状态的过程称为恢复。

一种简单的方法是让主服务器延迟任何新更新的处理，直到新副本从任何现有副本复制准备好的列表。或者新的副本作为候选次副本加入，主节点继续处理更新，并将准备消息发送给候选备份对象。如果主副本无法从新副本获得确认，则主副本将终止该副本的候选资格。

除了记录来自主副本的准备消息中的新更新之外，候选备份副本还从任何现有副本中获取它尚未拥有的准备列表的部分。当候选副本最终赶上时，它要求主服务器将自己添加到配置中。如果候选资格尚未终止，主服务器将与配置管理器联系，将候选副本作为备份服务器添加到配置中。

在恢复期间将状态转移到新的复制副本可能代价高昂。对于从未在副本组中的复制副本，完全状态传输是不可避免的。有些情况下，由于错误、网络分区或其他暂时性故障而从副本组中删除了副本。当这样一个过时的复制副本重新加入组时，最好让新的复制副本执行追赶恢复，这只会获取复制副本离开组时已处理的丢失更新。但是，如果旧副本离开组后发生了任何主副本更改，则不能保证旧副本上的准备列表是当前准备列表的prefix。

2.5正确性

假设在任何时候配置管理器定义的当前配置中至少存在一个非故障副本，查询添加到线性化的执行中，主进程处理由提交列表表示的状态的每个查询；查询自然是在该提交列表中的所有已提交更新之后以及之前完成的所有查询之后添加的。在任何时候，单个主都在处理所有查询，查询可以保持线性化的执行。

为了持久性，如果客户机接收到更新的确认，则发送确认的主服务器必须已将请求插入到其提交列表中。

对于进度，假设configuration manager最终返回每个重新配置请求的响应（Paxos在合理的时间假设下会返回一个结果），副本组最终将重新配置为仅包含非故障副本的配置。此时，将根据数据复制协议处理和确认所有请求。

2.6实施

实际上，副本并不像抽象模型中描述的那样维护准备好的列表和提交的点。它们的最佳实现方式取决于要复制的数据的语义。基于复制协议，实现必须有效地支持三种类型的操作。

查询处理：处理对提交列表对应状态的查询。

对帐期间的状态转移：使副本上的准备列表与新的主副本相同。状态传输的结果可能会删除备份服务器上已准备好的列表中的某些未提交项。

恢复期间的状态传输：将准备列表中所需的部分从副本传输到加入服务器。作为状态传输的结果，加入服务器上准备列表中的某些未提交项可能会被删除。

允许有效处理查询的一种自然方法是将提交的请求按序列号顺序应用于应用程序状态。尚未提交的已准备好的请求可能需要单独维护：这些请求不会直接应用于应用程序状态，因为它们可能需要在状态转移期间被撤消：撤消操作很棘手，可能需要单独的撤消日志。

对于更新，新的主请求只需发送所有准备好的和未提交的请求。为了加快追赶恢复，副本还可以在内存或磁盘上维护最近提交的更新。

为了提交更新，备份服务器必须首先在准备列表中记录更新，然后在得知请求已提交时将更新应用于应用程序状态。这通常涉及对每个提交的请求进行两次磁盘写入。

一种优化方法是批量更新应用程序状态，方法是首先将它们应用于状态的内存映像，然后定期将新映像写入磁盘。单独的prepared列表不仅保留尚未提交的已准备请求，还保留尚未反映在磁盘应用程序状态上的已提交请求。当内存中的状态因断电而丢失时，需要后者来恢复已提交的更新。

设计仅append的应用程序状态。在系统维护仅追加应用程序状态的情况下，以后的更新只需要追加，而不是覆盖旧状态，可以将准备列表直接应用到仅追加应用程序状态。 这是因为撤消仅追加状态的更新很简单。
在这种设计中，当从主服务器接收请求时，辅助服务器以串行顺序将请求直接应用于应用程序状态，从而有效地使用应用程序状态来维护其准备列表。主节点在提交请求之前仍会等待所有备份节点的确认，从而有效地将应用程序状态用作其提交列表。当从主服务器获取有关提交点的附带信息时，备份服务器会惰性的维护提交点。

为了进行对帐，当新的主节点p开始时，每个备份节点s都确保提交点之后的状态部分与p上的状态相同。 为了进行恢复，副本仅复制从其提交点到当前主数据库的所有内容。

2.7讨论

在本小节将讨论框架的一些设计细节，并探索其他设计选择。

configuration manager的可用性和性能。使用集中式configuration manager可以简化系统管理，因为它是维护系统中所有副本组配置的中心点。更重要的是，这种分离还简化了数据复制协议，并允许在大小为n的副本组中容忍n～1个故障。

为了实现高可用性，配置管理器本身使用复制状态机方法和标准Paxos协议来实现。该服务通常部署在少量（比如5个或7个）固定服务器上，并且可以容忍不到一半的服务器不可用。与集中式锁定服务不同，configuration manager的不可用性不会影响其他服务器的正常操作。

configuration manager不可能成为性能瓶颈。configurationmanager不参与正常情况下的请求处理，但仅在副本组重新配置时才涉及。通常Paxos在一轮通信中处理一个命令，每个成员服务器将更改提交到本地磁盘。通常对configuration manager的每个请求（即使是读取请求）都需要执行一致协议。

副本组故障期间的耐久性。在前面的部分中，我们将说明复制协议能够容忍大小为n的副本组中的n～1个故障。实际上，在某些情况下，例如在电源故障期间，副本组中的所有服务器都出现故障。在这种情况下，只有当组中的某些副本恢复联机时，副本组才能取得进展。如果最新配置中的所有复制副本都永久性地失败，则会导致数据丢失。如果在最近的配置中至少有一个副本恢复联机，我们的复制协议允许系统在没有数据丢失的情况下恢复，只要configuration manager也从电源故障中恢复。对于使用Paxos协议实现的configurationmanager，如果大部分的configurationmanager服务器都恢复了，那么管理器可以恢复。

为了实现对整个副本组的暂时性故障的持久性，所有副本都在持久性存储上维护其准备列表和提交的点。当复制副本从故障中恢复时，它会联系configuration manager，以查看它是否在当前配置中仍然是一个复制副本。

主/备份与Paxos。使用主/备份范式的另一种选择是采用Paxos范式。

在Paxos中，请求只有在大多数副本上准备好之后才被提交。即使对于查询请求也是如此，我们的协议中只能对主副本进行查询。

在主/备份范例中，更新请求只有在所有副本上准备好之后才提交，而不是像Paxos那样在大多数副本上提交。两个协议中不同的量词选择有几个含义。

首先使用paxos少数副本的故障对性能的影响最小。相反，在我们的主/备份协议中，任何副本的缓慢都会导致协议速度减慢。任何复制副本的故障都会暂停进程，直到重新配置将该复制副本从副本组中删除为止。租约的超时值必须适当设置：较高的值在副本失败期间转化为更高的中断时间，而较低的值可能导致误报错误，从而从副本组中删除一个无故障的慢速副本。错误误报会降低系统的弹性；我们的协议有助于快速恢复副本以快速重新加入，从而减少漏洞窗口。

其次，当大部分副本不可用时，Paxos无法处理任何请求。然而，在我们的协议中，副本组可以在configurationmanager的帮助下重新配置，并且只要至少有一个副本可用，就可以继续运行。

第三，在单独的配置管理器的帮助下，协议中的重新配置非常简单。使用Paxos，副本组可以通过一致决策来重新配置自己，新复制副本必须与当前配置中的大多数副本联系才能正确传输状态。

在实践中，哪种选择提供了更好的折衷方案，这是值得商榷的。我们选择主/备份模式主要是因为它的简单性。

弱化强一致性。强一致性本质上有两个要求。首先，所有副本必须以相同的顺序执行同一组更新。其次，查询返回最新状态。弱化强烈的一致性可能有好处，弱化第一个要求会导致副本之间的状态转移，这通常要求系统检测并恢复到一致的状态，同时也要求客户端处理不一致，此类系统的例子包括Coda、Sprite、Bayou、CONIT、PRACT和GFS。

 

3   基于日志的分布式存储系统的复制

我们将通过基于日志的分布式存储系统探讨所提出的复制框架的实际方面。

下图显示了（非复制的）基于日志的存储系统的一般体系结构。系统维护应用程序数据的磁盘映像，以及捕获磁盘映像更新的内存数据结构。为了持久性，系统还为只在内存中维护的更新保存应用程序日志。

当系统接收到更新时，它将请求写入日志以获得持久性（步骤1），并将请求应用于内存中的数据结构（步骤2）。当服务器重新启动时，将重放日志以重建内存中的状态。定期（在内存中的数据结构用完内存之前），在磁盘上为内存中的数据结构创建一个检查点（步骤3）。创建检查点后，可以从日志中截断已反映在磁盘检查点中的所有更新日志条目（步骤4）。系统可以选择存储一个或多个检查点。检查点中反映的更新定期与磁盘映像合并，以创建新的磁盘映像（步骤5）。系统可以选择不带检查点的合并：内存数据结构中反映的更新直接与磁盘映像合并。

我们选择通用的形式是因为它很好地覆盖了特殊情况，因为它准确地反映了一些实际系统（如Bigtable）的工作情况，而且在某些情况下，检查点的维护可以加快协调的速度。查询使用内存中的数据结构、磁盘上的检查点和磁盘映像来提供服务。值得指出的是，这种基于日志的设计消除了随机磁盘写入，并将其转换为更高效的顺序磁盘写入。

3.1逻辑复制

在上面的复制策略中，复制只是应用于整个系统状态：每个副本支持与原始非复制系统相同的接口，并且能够处理相同类型的更新和查询。

这是符合逻辑的，因为副本上的状态在逻辑上是相同的。副本可能保持不同的物理状态，副本可以单方面决定何时检查点和何时合并。

逻辑复制：因为应用程序状态append-only，所以我们选择与应用程序状态分开维护准备列表。我们可以通过维护一个既作为应用程序日志又作为准备好的请求的存储的日志来消除向准备列表写入更新的成本。为此，我们用三个字段扩充包含客户机请求的日志条目：配置版本、序列号和最后提交的序列号。日志条目包含具有相同序列号和较低配置版本的任何其他条目，当准备请求在主更改期间被撤消时会发生这种情况。因此应用程序日志由具有提交序列号的所有未包含的日志条目组成，而未提交的日志条目属于准备列表。

在第一阶段，当接收到包含请求、配置版本、序列号和最后提交的序列号的准备消息时，复制副本会将消息追加到日志中。在第二个阶段，当提交一个请求时，它将应用于内存中的数据结构，但是应用程序不再需要再写日志了，因为请求已经在日志中了。

应用程序在检查点后截断其日志。但是只有与提交的和检查点更新对应的日志条目才会被截断。我们的复制协议只需要准备列表的提交后缀，截断期间会保留了所有这些条目。每个检查点反映序列号范围内的更新，该范围与检查点关联。我们还将磁盘映像与它所反映的最后一个序列号相关联。这些相关的序列号可以帮助确定在追赶恢复期间需要哪个状态。

逻辑复制的变体：处理内存中数据结构的更新、生成检查点以及合并所有消耗资源（如CPU周期和内存）的成本可能很高。在逻辑复制中，这些操作既在主服务器上执行，也在备份服务器上冗余地执行。

一种做法是只让主服务器执行这些操作。然后在所有副本上复制这些操作的结果。因此我们引入逻辑复制方案的变体，称为logical-V。在logical-V中，只有主服务器保持内存中的状态。

当从主服务器接收到更新时，备份服务器只是将请求追加到日志中，而不将请求应用到内存中的状态。备份服务器在生成检查点时从主服务器获取检查点。只有当与备份服务器上的日志项对应的更新被丢弃或提交并反映在本地检查点时，才能丢弃备份服务器上的日志项。

Logical-V表示逻辑复制的一个折衷。在logical-V中，备份节点消耗更少的内存（因为它们不再维护内存中的结构）和更少的CPU（因为它们不再生成检查点，这涉及到压缩）。但是，logical-V确实会产生更高的网络负载，因为检查点会在副本之间传输。更重要的是，logical-V中的主故障转移更耗时：要成为新的主节点，备份服务器必须重播日志以重建内存中的状态并生成所需的检查点。

3.2分层复制

基于日志的系统中的持久状态由检查点、磁盘映像和日志组成。它们都可以作为文件实现。可以将基于日志的存储系统看作由两层组成，其中下层提供持久文件存储，上层将应用程序逻辑转换为对文件的操作。

分层的观点导致了另一种设计，即将复制分别应用于两个层。在较低层，一个简单的仅附加文件抽象就足以支持附加新日志条目和创建新检查点等操作，可以使用第2.6节中概述的仅附加状态的设计来进行文件复制。

拥有较低层的文件复制也很有吸引力，因为抽象是可重用的，并且简化了上层的逻辑。较新的分布式存储系统，如Petal上的fragipani、RLDev上的Boxwood和GFS上的Bigtable，都使用分层的方法，并且在较低层有主要的复制逻辑。

在上层，对于每一段数据，一些所有者服务器负责接受客户机对数据的请求，维护内存结构，并向下层的文件写入（附加）内容，以保持持久性和可靠性。例如，要编写日志条目，上层只需请求下层将该条目附加到日志文件中。上层不关心日志的维护位置、是否复制日志或如何复制日志。下层不知道也不关心正在操作的文件的语义，不管文件是日志还是检查点。

较低层的复制并不能完全消除上层对容错的需要：当所有者服务器发生故障时，必须由新的所有者服务器来承担其责任。在以前的系统中，使用一个单独的分布式锁服务来确保在上层为每个数据段选择一个唯一的所有者服务器。我们的一个重要观察是，与其发明和部署新机制，相同的复制逻辑可以在上层重用，以选择唯一的所有者来接受和处理客户机请求：选择唯一所有者的问题与实现主节点的复制框架的配置管理部分相同。

一种自然的设计是选择在较低层管理数据的副本组的主服务器作为所有者服务器。有两个主要优点。首先，我们在上层从下层的复制协议中获得了一个“免费”的故障转移机制，而不需要分布式锁服务，也不会产生任何额外的开销。当所有者服务器发生故障时，将在较低层选择一个新的主服务器，它将是新的所有者服务器。其次，这种安排确保数据的副本始终驻留在所有者服务器上，从而减少网络流量。

3.3日志合并

系统通常维护多个副本组。正如GFS和Chain Replication[29]所倡导的那样，服务器参与一组不同的副本组，以便在服务器发生故障时分散恢复负载。假设每个副本组都有一个逻辑关联的日志，那么每个服务器都必须维护多个这样的日志。使用日志记录的好处可能会减少，因为写入多个日志会导致磁盘头定期查找。

一种解决方案是将多个日志合并到单个物理日志中，如Bigtable中所做的那样。复制方式的选择会影响日志的合并方式。对于logical和logical-V，日志条目显式地发送到辅助对象。然后，每个服务器都可以将日志条目放在一个本地物理日志中。生成的本地物理日志包含服务器所属的所有副本组的日志条目，无论该服务器是组的主副本还是辅助副本组。在这个方案中，系统中的每台服务器只有一个本地物理日志。

对于分层复制，服务器将其作为主数据的所有数据的日志条目写入较低层的单个复制日志。这会有效地合并服务器为主要副本组的所有日志，但不会合并服务器为辅助副本组的日志。

系统中有n个服务器，每个服务器都是某个副本组的主服务器，在分层方案中，将有n个复制日志。如果每个日志被复制k次，系统中将有kn个单独的本地日志。这与逻辑和逻辑-V情况下的n个本地日志不同。在分层方案中，无法保证故障转移期间新主服务器所需的日志条目是本地的。这是因为不同副本组的日志条目合并到一个日志中。这些不同的副本组通常在不同的服务器上有其辅助副本，以实现并行恢复。因此，日志的辅助副本不能与所有这些辅助副本位于同一位置。相反，在logical-V情况下，在故障转移期间，所有需要的日志条目都保证是本地的，但是每个服务器必须解析合并的日志文件，以找到与新的主副本相关的必要日志条目。对于逻辑复制，当副本从断电重新启动时，副本将重播其本地日志以重建内存中的状态，但新的主副本在故障转移期间不需要重播其本地日志，因为它保持内存中的状态。