概览

Oracle Berkeley DB Java版高可用性（JE HA）是一个支持replication特性的事务性数据管理系统。JE HA提供的高可用特性可以极大提升数据读操作的可扩展性（scalability）及其性能。

这份白皮书将详细介绍JE HA的关键概念和主要特性，从而让开发人员和应用软件设计者理解如何最好地利用JE HA解决软件开发中特有的数据管理问题。

本白皮书同时也讨论了软件架构师在设计基于JE HA的应用时，如何从技术的角度权衡各方面的性能与资源。

基本介绍

Oracle Berkeley DB Java版本（JE）在最新的发布版本中引进了一个新特性，即高可用性（high availability，简称为HA）。JE是一个事务性的数据管理系统，最新版本的JE 便是在之前版本的基础上做了扩展，加入了HA的特性。

用户在应用程序中可以利用JE的直接持久层（DPL）创建用于存储Java对象的索引数据库。在JE中，多个数据库操作可以包含进一个事务（transaction）中，从而得到事务所提供的原子性、一致性、分离性和持久性（ACID）等事务特性。如果应用程序或者系统发生故障，JE的故障恢复机制（recovery）可以使应用程序的数据恢复到一致的状态。

JE HA是一个嵌入式数据管理系统，它在具备JE全部功能的基础上，为JE提供replication规则，即“主节点（master）可以执行读/写操作，副节点（replica）只能执行读操作”。这种规则意味着数据库读与写操作都可以在单个主节点中进行，而在副节点上只能进行读操作。如果主节点发生故障被关闭，那么JEHA将在所有副节点中自动选择其中一个作为新的主节点，这样，所有的读写操作就可以在新的主节点中进行。作为一个嵌入式的类库，JE HA可以广泛应用在各种硬件配置和环境中。

JE HA主要解决以下三个应用上所面临的难题：

• 在不允许宕机的应用场景中，能够迅速进行热备切换（failover）；
• 通过配置多个只读副节点以提供读操作的可扩展性；
• 在实现数据持久性（durability）时，允许应用程序将数据提交到（快速的）网络，而不是（缓慢的）磁盘，从而使事务的提交更加高效。

然而，JE HA不适用于需要对写操作进行扩展的应用场景。这类应用场景需要数据分区（data partition），然后在每一个数据分区中运行一个JE HA的环境。同样，JE HA也不提供与其他数据库进行数据同步的功能。本白皮书不再赘述这两方面的应用。

除去上述两个应用场景，JE HA可以广泛应用在各种环境中。下面分别进行简单的介绍。

• 基于小型局域网的数据复制备份：基于数据中心的服务可以向本地的多个机器提供数据，比如一个公司网站。这种服务由几台安放在同一个数据中心的服务器提供，这些服务器通过高速的局域网互联。
• 广域数据存储：广域数据存储服务可以存储大量的账户信息，用户可以在全球任何地方访问这些信息。这种服务由许多分布在全球多个地方的数据中心的服务器提供。这些服务器通过数据中心之间的高速网络进行通信。
• 主节点/从节点：提供主从节点机器的热备切换。

JE HA可以在广泛的应用环境中对数据进行replication，而单独一种数据管理和replication机制并不能适用于所有环境。因此，JE HA可以让应用程序控制主副节点之间的数据一致性程度，事务持久性，以及提供了其他可以提升性能、可靠性以及数据可用性的各种设计选择。这份白皮书的目的就是介绍这些选择和配置，并且提供足够的细节便于用户的理解，这样用户在设计应用程序时可以做出正确的选择和取舍。

JE HA概述

这一章节将描述JE HA的总体架构和关键概念。

下文中，术语“数据库”（Database） 用于表示一组键/值对（key/value pair）数据集，这些键/值对数据集共享一个索引数据结构，它对应于关系型数据库管理系统（RDBMS）中表（table）的概念。术语“环境”（Environment）用于表示一组具有逻辑关系的Berkeley DB数据库集合，以及相关的元数据（meta-data）和内部文件。每个环境用一个文件目录命名。可以看出，环境就是RDBMS中数据库的概念。也就是说，下文中涉及的数据库就是RDBMS中的表，而环境就是RDBMS中的数据库。

JE HA将一个环境在一个replication group中的各个节点之间进行replication操作。一个环境就是一个replication单元。在一个replication的环境中，所有数据库都支持replication操作和满足事务性。

Replication group

一个replication group是一个节点集合。这些节点都将参与到环境的replication过程中。一个replication group由两种节点组成：可选（Electable）节点和监测（Monitor）节点。

每个可选节点都拥有一份可进行replication的环境副本，它既可作为主节点，也可作为副节点。一个可选节点将通过一种分布式的两阶段投票协议（distributed two-phase voting protocol）而被选举成为一个主节点。这种投票协议将可以保证每次仅选举出一个主节点。所有参与选举的节点中，拥有最新环境数据的节点将被选为主节点。一个可选节点可以进入以下几种状态（但每个时间点只能进入一种状态）：

• 主节点（Master）状态：一个节点将通过简单多数（或者叫过半数，simple majority）原则，在众多可选节点中被选举为主节点。一个节点变成主节点后可以进行读和写操作。
• 副节点（Replica）状态：副节点通过replication stream与主节点进行通信。Replication stream用于跟踪记录在主节点中所做的任何更新。在后续章节中将会对replication stream做详细的介绍。副节点只支持读操作。
• 未知（Unknown）状态：一个节点处于未知状态意味着此节点不能识别主节点，并不断尝试着寻找主节点，或者联系其他成员节点来进行主节点选举。处于未知状态的节点将不断尝试过渡到主节点或者副节点状态。这种状态的节点如果能满足事务性的一致性要求（下文将详细描述），那么它仍然可以进行读操作。
• 分离（Detached）状态：一个节点处于分离状态意味着此节点已经被关闭（shutdown）。处于分离状态的节点仍然属于replication group中的成员，但它并不是一个活跃节点（active node）。同样，如果一个节点不处于分离状态，则意味着它是活跃节点。

注：为了简略，术语“主节点”和“副节点”在以下的讨论中将用于表示replication group中的某节点正处于主节点状态和副节点状态。

监测节点（monitor node）用于跟踪和监视一个replication group中所有可选节点的当前状态。所有新节点的加入和当前节点的删除所引起的replication group结构的变化都会被监测节点监听到。监测节点同时也能监听所有可选节点的动态状态变化（即此节点处于活跃状态抑或分离状态）。监测节点没有任何持久的状态，也不拥有可进行replication的环境副本。应用程序可以利用监测节点将所有的写请求路由到replication group当前的主节点中，同时将读请求路由到replication group的副节点中。另外，只有应用程序需要调用监测节点，监测节点才会被replication group所创建。也就是说，监测节点并不是必需的。

一个replication group中的多个副节点可以分布到多台物理机器中，这样可以保证单个机器上的故障或者宕机不会影响到同组中的其他节点。但不同replication group中的多个副节点运行在同一个物理机器中的情形也并不少见。这种配置在某些应用场景中是十分有用的。例如，实现数据分区，这种应用场景在后面章节会有详细描述。

图一清楚描述了一个replication group G中的主要元素：三个可选节点（N1，N2 和N3）以及两个监测节点（M1和M2）。

（图一） Replication group G。可选节点：G（N1），G（N2） 和G（N3）。两个监测节点：G（M1）和G（M2）。

Replication  group的生命周期

一个replication group总是从一个节点开始，这第一个节点会被默认成为主节点。一个可进行replication的环境可以是空的，或者是一个已存在的独立（standalone）的环境。但这个环境被转换成一个可进行replication的环境格式之后，可以往这个replication group中加入新的可选节点，这样会增加组的大小，同时也会增加主节点选举和数据持久性所需要的有效可选节点的数目（quorum）。

一个新的可选的节点通常需要经过以下几步才能真正参与到replication group中（即成为活跃节点）：

• 新节点找到主节点，并且提供自身的配置信息。
• 主节点把新节点的信息存储到内部一个用于记录组节点信息的可进行replication的数据库中。其他可选举节点将通过replication stream获知新节点的信息。至此，新节点可被视为是replication group中的一名成员节点。
• 此新成员节点开始初始化它所拥有replication环境副本。如果某些日志文件已经被JE 的日志清除器（log cleaner）所回收，那么新节点将调用一个叫做Network Restore的操作，从组内某一个成员节点中直接拷贝一份日志文件，并且用这份日志副本作为重演（replay）replication stream的起始点。
• 新节点重演replication stream，直到它满足一致性的要求为止。

满足一致性要求之后，新成员节点就成为一个活跃的副节点。它将可以为应用程序提供读操作，并且可以在热备切换过程中被选为主节点。

由于监测节点不需要为应用程序提供数据的读写服务，所以它并不拥有可进行replication的环境副本。因此加入一个监测节点很简单，只需要在主节点所拥有的环境副本中加入此监测节点的信息。这样，其他成员节点可以利用该信息与监测节点通信，向监测节点通知有关组内的变化，例如某次选举，或者组内成员的组成变化（新增节点或者删除节点）。同样，由于没有环境副本，当监测节点在每次启动的时候，它必须查询其他可选节点以判定组内当前成员节点的构成和状态。

如果节点运行的机器发生故障或宕机时，replication group有可能会由于组内节点数目无法达到有效可选节点数而无法运行。这些发生故障的节点可以通过JE HA提供的API显式地进行删除，这样余下的成员节点数目便可以满足有效可选节点数的要求，从而replication group可以恢复到正常的运行状态。当然，节点的删除往往意味着数据可持久性的降低。

Replication stream

所有发生在主节点上的写事务操作都将通过一种逻辑意义上的replication stream被复制到所有副节点中。这种replication stream是建立在TCP/IP连接之上，这种连接是主节点和每个副节点之间的专用连接。Replication stream包含主节点上的一些逻辑变化，这些逻辑变化是各种发生在环境中的数据库事务操作，如插入（insert）、更新（update）、删除（delete）、提交（commit）和中止（abort）等等。这些逻辑操作将从当前主节点日志文件中的日志条目（log entry）计算出来并且复制到各个副节点中，然后在每个副节点中通过高效的内部重演机制执行这些操作。

为了能让副节点能成功重演replication stream，这些日志条目必须是连续的。它们不能是一些被JE的日志清除器删除掉的条目。

为了保证这一点，JE HA把日志分成两部分：

• 可移除日志，一般在日志的前端，由过时的数据组成，日志清除器可以将其删除。
• 不可移除日志，一般在日志的末端，所有在这部分的日志都是新的，日志清除器不可以将其删除。只有这部分日志才能用于构造replication stream。这部分日志会随着新条目的加入而不断增大。一旦不可移除日志在所有副节点上重演，就会转换为可移除日志。

下图描述了一个具有三个节点的replication group：节点1是主节点，节点2在重演日志时落后最多，所以节点2被用于决定可移除和不可移除日志。所有没有被节点2重演过的日志条目都会组成不可移除日志。在这个例子中，节点1的日志文件5和日志文件6，以及节点3的日志文件4和日志文件5组成了不可移除日志。这些文件在节点2进行更多重演之前都不能被回收。

（图二）可移除和不可移除日志

只要副节点能进行处理，主节点将一直异步地向副节点发送数据的日志信息，即使主节点中的事务还在进行或者这些事务还未提交。如果主节点中的某个事务最后被取消（abort），副节点中的同个事务同样会被取消。然而，应用程序的某个线程有可能会为了满足某个特殊事务对持久性的要求，会进行等待直至该特定事务在一个或多个副节点上提交。对于这类事务，副节点将通过向主节点发送确认响应明该事务已在副节点上提交。但这并不意味着主节点中的后续操作会被阻止，因为主节点在等待响应的过程中可以继续进行其他事务性操作。

对于主节点和副节点来说，主节点往replication stream发送写操作信息和副节点从replication stream读取（并且重演）这些操作是异步的。一旦应用程序创建了一个新日志条目，主节点就能将该日志条目写入复制流。副节点一旦从replication stream读取了这个操作信息，就可以重演该操作。并且，如果主节点需要，副节点可以在重演操作之后向主节点发送一个确认操作已经提交的应答信息。

Heartbeat

除了向副节点发送日志信息，主节点还会定期向副节点发送heartbeat。如果没有收到主节点发来的heartbeat，副节点将认为主节点或网络可能出现故障，并且发起一次主节点选举来解决这次潜在的问题。在任意的时间点，副节点在重演replication stream时都有可能滞后于主节点，所以在那一时刻副节点的环境可能会与主节点不一样（尽管在副节点赶上主节点之后，这些环境最终都将一致）。副节点将会利用heartbeat中的信息来判断在重演replication stream的时候它落后于主节点的程度，从而可以让副节点满足读一致性的要求（读一致性的要求决定了什么样的滞后程度是可以接受的）。

应用程序架构

JE HA建立在JE的基础之上，所以共用了JE大部分的API。然而，基于JE HA的应用程序是一个分布式的应用程序，这会带来一些额外的问题，而解决这些问题的最佳时机是在对应用程序的架构进行初始设计的时候。在这一章节中，我们将对JE HA的一些主要特性做一个概述，这些特性会对基于JE  HA的应用程序的架构设计有直接的影响。

在应用程序中嵌入数据管理

这一小节将会基于JE来讨论什么是在应用程序中“嵌入”数据管理，并且会将此讨论延伸到JE HA中。

在谈论JE的时候，我们通常用术语“嵌入式（embedded）”来描述应用程序和数据管理能力之间的关系。这些通过JE的类库实现的数据管理能力是被嵌入到应用程序中的。由于JE是被应用程序直接使用和管理的，所以应用程序的用户或者管理员都不需要注意到JE的存在。这种应用程序有可能运行在一个嵌入式设备中，比如一台手持设备，一台桌面机器或者一个数据中心。事实上，JE提供的是存储层的功能，因此它往往是作为存储引擎来为应用程序提供数据管理服务。

对比其他传统的客户端-服务器端（client-server）数据管理架构，嵌入式的数据管理架构有以下一些优点：

• 数据将以原始的形式进行存储和读取，而不需要在不同的数据模型（比如，关系型（relational）数据模型）之间进行转换。应用程序可以将一些结构体或者复杂的对象直接进行序列化后存储进JE的数据库中。
• 不需要数据库管理员（DBA）。相反，应用程序将数据库配置和管理直接纳入到它自身的配置和管理中，其结果仅需在应用程序中增加几个新的配置。
• 数据库能够自动恢复（recovery）。终端用户不会注意到任何单独的数据库恢复过程。相反，应用程序在打开一个数据库的时候，JE只在必要的时候会自动并且透明地进行数据库恢复。类似的，当应用程序关闭时，数据库也会被自动关闭。
• 性能会优于传统的客户端-服务器端架构，其原因是嵌入式结构将消除进程之间通信的额外消耗。这种进程间的通信通常发生在应用程序和数据管理服务之间。

对于JE HA来说，应用程序通常运行在replication group中的每一个可选节点中，并且都拥有一份JE 环境副本。在基于JE HA的应用程序中嵌入数据管理的方式与基于JE是一样的。运行在主节点中的应用程序可以进行读和写的操作；而运行在副节点中的应用程序则只能进行读操作。

写操作管理

应用程序负责将应用层面上对数据库的所有修改请求（例如，通过JE对数据进行插入、删除和修改操作，以及对数据库的建立、重命名、清空和删除操作等等）提交到主节点上。应用程序有两种方式可以向主节点发送写操作请求：

• 基于副节点的转发：每一个副节点上的应用程序时刻与主节点保持联系，并且能将所有写操作请求转发到当前主节点。
• 基于监测节点的路由：应用程序在监测节点中运行一个路由程序，该路由程序可以将写操作请求路由到当前主节点，并且能够将读操作请求路由到所有合适的活跃节点以达到负载平衡。

当你在以上两种方式做出选择时，必须考虑以下几个因素：

• 与当前存在的负载平衡机制的整合。在某些情况下，例如，一个基于硬件的负载平衡器，并不容易甚至不可能将一个中间级的路由器整合进来。在这种情况下，基于副节点的转发将是最好的选择，因为这种机制不会干扰到当前负载平衡机制。
• 写操作请求的延迟性。利用基于副节点路由来转发一个写操作请求会带来额外的网络跃点（network hop），因此会增加写操作请求的延迟时间。这种延迟的增加在某些应用程序中并不希望看到，例如这些应用程序要求较低的写延迟和较短的反应时间。
• 网络利用率。如果写请求的平均有效载荷很高，操作请求的转送机制会与replication stream竞争网络资源，这样反而会影响replication性能。如果应用程序的写请求有效载荷很高，那么基于监测节点的路由会是更好的选择。
• 操作请求的格式。如果采用基于监测点的路由方式，可能需要对应用程序的操作请求格式设计成能够易于识别其是否为写操作。例如，网络应用可以利用URL的格式协议来让路由器能识别读操作和写操作。当采用基于监测点路由方式时，必须要考虑到设计这些请求格式时的额外需求。
• 路由器的可用性。对于高可用性，应用程序的设计者必须考虑到使用多路由的情况，这样路由器就不会是导致故障发生的热点。在采用基于监测点路由时，多路由会带来额外的复杂性。

对这两种方式的选择是对简单性和性能之间的权衡考虑。基于监测点的路由方式也许会提供更高的性能，但也会带来额外的复杂性。基于副节点的转发方式实现起来相对简单，但相对来说或许没有那么好的性能。

由于不同应用程序中的操作请求的格式和协议各有不同，JE HA并不提供任何机制用于传送成员节点之间或者路由器和成员节点之间的操作请求。应用程序必须自己提供这样的传送功能。

不过，JE HA提供接口用于判定replication group中的成员节点，并且能跟踪当前主节点的状态。

以下几个章节将描述JE HA所支持的一些功能，这些功能将会帮助用户实现上述的两种方式。

基于副节点的转发

（图三）基于副节点的转发

一个基于JE HA的应用程序通过一个支持replication的环境的句柄（replicated environment handle）来访问其环境副本。这个句柄的API可以为应用程序提供以下功能：

• 决定节点当前状态。例如，可以查询某个节点当前是主节点或是副节点。
• 将一个状态变化监-听-器（state change listener）和一个句柄相关联。这样，状态变化监-听-器将会持续收到来自主节点的各种信息。

利用这些API，应用程序可以知道它当前所在的节点是否是主节点。如果不是，那么它可以将它接收到的写请求操作转发到当前的主节点上，过程如图三所示。用于转发写请求操作到恰当的节点的机制实际上是应用程序所提供的，并不会涉及JE。

基于监测节点的路由

（图四）基于监测节点的路由

监测节点并不拥有环境的本地备份。它唯一的作用就是用来跟踪replication group当前的状态。路由程序可以根据这些状态信息来将读写操作路由到replication group适当的节点中去。路由程序是应用程序基础架构中的一部分，一般来说不会包含任何应用程序特有的逻辑，但有一个例外：路由程序有足够的信息可以识别读操作和写操作请求格式。

为了实现这种方式的路由，应用程序将一个监-听-器和监测节点句柄（monitor handle）相关联起来。监-听-器接受三类消息：

• 组内成员节点组成的变化。组内成员节点的加入和移除都会通知给监-听-器。
• 组内当前主节点的变化。
• 组内节点当前状态的变化。也就是，此节点当前是否是活跃节点。

路由程序一旦接收到应用程序的操作请求，就会判断此请求是否是写操作请求。若是，路由程序将利用监测节点来确定哪个节点是主节点，从而将此写操作请求转发到主节点。对于读操作请求，它利用监测节点来确定组内的当前节点组成，选择一个活跃节点来完成读操作请求，从而在此过程中实现负载平衡。

更复杂的路由程序的实现将会根据键值范围（key ranges）的分布以及数据读取的方式，将每个读操作请求转发到某个最有可能在缓存中拥有此被读数据备份的成员节点中。因此可以说，该方式实现了一种读分区（read partition）数据存储模式。

可选节点的热备切换（failover）

在程序运行过程中，主节点的选举过程是透明的。因此，应用程序必须允许由于选举而产生的各种状态变化，这样应用程序才能在状态变化中继续运行。下面几种状态的变化均是由于热备切换所导致的：

• 如果当前主节点发生故障，那么某个可选节点将会由副节点通过选举转变成主节点。在利用基于监测节点路由机制的应用程序中，这种转变意味着，一个之前只能接收读操作请求的节点，现在开始接受和处理写操作请求。而在利用基于副节点转送机制的应用程序中，新的主节点必须停止转发写操作请求，相反，它必须开始接受来自其他副节点的写操作请求。
• 当前的主节点可能转变成副节点。这种情况很少发生，一般会涉及到临时网络分割（network partition），这时候主节点不能参与节点选举。因此，剩下的节点会重新选举一个新的主节点。在该情况下，由于某些试图在此副节点（之前是主节点）上进行写操作的事务会失败，并抛出异常，因此变成副节点之后的该主节点必须转发所有它接收到的写操作请求，或者拒绝这些请求。
• 由于热备切换，一个副节点可能会将自己与发生故障的主节点间的通信切换到一个选举出来的新主节点。通常这种转变对应用程序是透明的。JE HA只需重新与新的主节点建立replication stream。在某些罕见的情形下，JE HA有可能需要进行恢复操作，并撤销某些之前已经提交的事务。在这种情况下，replication环境的句柄便会失效。因此，应用程序必须重新建立环境和数据库的句柄，并且通过访问之前环境句柄重新获得所有被缓存起来的瞬时状态。

JE HA事务配置选项

支持Replication的环境必须是是事务性（transactional）的。支持Replication的事务提供了额外的选项用于对事务进行配置，这些选项对应用程序的性能有直接的影响。对这些配置选项的选择实际上是对持久性、写可用性、副节点读一致性以及性能等各方面的权衡考虑。这一章节将具体描述这些配置选项，并且突出讨论如何进行这种权衡考虑。

持久性选项

JE提供了三种不同程度的持久性，分别对应于已经提交的数据在磁盘上所具有的三种不同的持久状态。

• SYNC：已经提交的更新被写到磁盘上。该级别的持久性能够保证在机器发生故障的时候，已经提交的数据不会被丢失。但是这种持久性并不能保证在媒介（比如磁盘）损坏的时候数据没有丢失。
• WRITE_NO_SYNC: 已经提交的更新被写进文件系统缓冲区。该级别的持久性仅仅保证在应用程序发生故障时，已提交的数据不会丢失。如果机器不发生故障，这些已经提交的数据将最终写进磁盘。
• NO_SYNC: 已提交的更新只写进JE的内部缓冲区。在这一级别的持久性中，已提交的数据在应用程序发生故障的时候会丢失。

JE HA扩展了JE持久性的概念，即允许事务通过向快速的网络提交更新从而持久化数据，而不是提交到相对缓慢的磁盘上。因此，除了允许在主节点和副节点中设置以上提及的各种同步级别之外，JE HA还规定副节点完成事务重演之后向主节点发送一个提交响应。并不是所有事务的提交都会从副节点中返回一个响应。主节点只有在必要的时候才会明确要求副节点产生响应。如果一个副节点已经落后于主节点并且尝试赶上主节点，那么主节点将不会要求该副节点发送响应。

因此，JE HA的持久性有三个方面：

• 主节点上数据同步的程度。
• 对副节点返回响应数目的要求，这一要求在与事务相关的响应策略（Acknowledgment Policy，下文会有介绍）中有所规定。
• 在副节点返回提交响应前，副节点上数据的同步程度。

响应策略（Acknowledgment Policy）配置

响应策略配置提供三种可能的选择：ALL，SIMPLE_MAJORITY以及 NONE。

• ALL：该策略要求，在事务被主节点持久化之前，所有可选的副节点都必须向主节点发送响应说明它们已提交了这些事务。这一策略会保证较高的数据可持久性，因为在此事务被持久化之前，每个副节点都拥有一份该事务所做的更新操作的拷贝。该策略也保证副节点上较高的读一致性，这是因为所有副节点都能赶上主节点，并且在副节点处理replication stream的过程中没有滞后性。然而，该策略会降低replication group的写可用性，特别是在replication group的节点数较大的情况下。因为即使仅仅一个节点变成不可用，写事务提交操作都会失败。另外一个缺点是提交的延迟性会被提高，因为提交所需的时间将会由性能最差的副节点决定。
• SIMPLE_MAJORITY：该策略要求，简单多数（即过半数）的可选节点必须向主节点发送响应说明它们已经提交了事务。由于在事务被提交之后，该事务所做的数据更新的拷贝存在于过半数的副节点中，并且当其余的副节点赶上replication stream的进度时，这些更新最终会传播到这些节点中，因此该策略保证了中级别到高级别的持久性。如果在主节点上某次事务成功提交之后，主节点发生故障，选举程序将保证这些事务的更新不会被丢失。之所以有这个保证，是因为选举程序要求过办数的可选节点都参与到选举过程中，从而保证了至少一个节点既发送了事务提交响应又参与了选举过程。选举算法更进一步保证拥有最新日志的节点将被选举成为主节点，这样可以在产生事务的主节点发生故障之后保持这些更新。

“SIMPLE_MAJORITY”策略在副节点上的读一致性没有“All”策略那么高，这是因为主节点上事务产生的更新有可能没有被复制到并不发送事务提交响应的副节点上（由于只有过半数的副节点要求发送响应）。因此，对数据一致性的要求比较严格的事务会停滞在所有有滞后的副节点中，直到这些滞后的副节点赶上主节点。在正常情况下，这种滞后会很小，并且处于滞后中的副节点会迅速赶上主节点的事务。

“SIMPLE_MAJORITY”策略具备从中等级别到高等级别的写可用性，这是因为replication group允许节点发生故障，并且只要有过半数的节点保持可用，那么replication group便可以继续完成那些要求过半数持久性的写事务。由于主节点需要等待的节点数较少，所以“SIMPLE_MAJORITY”策略的性能比“all”策略要好，同样，主节点会向所有与它有通信的副节点发出响应请求，但它只需要等待到过半数的副节点做出反应即可。这样意味着提交延迟并不会取决于组内速度最慢的节点。

• NONE：在该策略下，事务的持久性不依赖于任何副节点发送提交响应。只要事务满足主节点上的同步策略，就可以认为该事务已经被持久化。由于并不能保证在事务提交的时候所做的更新已经被复制到其他副节点中，因此这种策略会导致较低级别的持久性（相对于不支持replication的JE环境）。如果在主节点上某次事务成功提交之后，主节点发生故障，那么这次事务所做的更新有可能会丢失。同样，该策略导致副节点上的读一致性较低，特别是在主节点负载很重并且没有必需的资源来维持replication stream的时候。因此，副节点有可能会远远落后于主节点。总而言之，这种策略会提供较高的写性能，但也会带来较低的持久性。

下面的表格总结了这三种响应策略的优缺点：

副节点读一致性

因为replication stream代表着被序列化的JE数据库日志，所以对replication stream的重演会导致副节点从一个事务的一致性状态转变到另外一个事务的一致性状态。副节点的重演机制保证所有事务性的更新会作为一个原子单元来提交，并且更新的过程会与其他正在进行的写事务隔离开，从而保证这些更新所要求的隔离性（isolation）。如果从单独一个节点的角度来看，副节点的所有行为完全具备事务性，并且满足通常的ACID特性，就如不支持replication的JE环境一样。这一章节将讲述关于副节点与主节点之间一致性的问题。

JE HA支持最终一致性（Eventual Consistency）。这种一致性模型并不能保证在事务在主节点提交的那一刻，所有副节点保持一致。然而，它保证在足够长的一段时间内如果没有新的更新产生，那么所有的更新会在所有的成员节点中传播，并且所有的副节点最终会与主节点共享一个一致的环境视图（environment view）。

由于所有在主节点上的读操作都具有绝对的一致性，所以所有要求绝对一致性的读操作都应该路由到主节点中。应用程序可以利用之前提到过的写转发（write forwarding）技术将这些读操作请求发送到主节点中。然而，对于并不要求绝对一致性的情况，在副节点的读事务开始时，读事务可以指定副节点滞后于主节点最大所能接受的程度。有两种方式可以量化这种滞后程度：

• 以时间衡量 – 在JE API的TimeConsistencyPolicy中有所描述。
• 以副节点在replication stream中的位置衡量 – 在JE API的CommitPointConsistencyPolicy中有所描述。

滞后的程度主要取决于主节点和副节点的负载，以及传输replication stream时的通信延迟。还有一种可能的情况是，某个副节点在一段时间内都没有和主节点联系，它需要赶上主节点在这段时间内所做的一些更新。

对一致性策略的选择取决于应用程序所采取的操作的性质。而对所选择策略的配置会直接影响到副节点上的读操作性能。接下来的章节将会详细描述这些策略以及它们的一些配置。

时间一致性策略（Time Consistency Policy）

这种策略描述了当副节点上的读事务开始时，副节点允许滞后于主节点的时间长短。假设t0是当前时刻（t0是时刻变化的），lag是所允许滞后的时间长度，那么所有在（t0 – lag）时刻之前在主节点上被提交的事务都必须在副节点上进行重演。而在这些事务进行重演之前，副节点上的读事务都不允许进行。值得强调的一点是，t0是时刻变化的瞬时间，而不是读事务开始时的固定时间，意味着副节点是在试图赶上一个随时间不断移动的目标。因此，这里的滞后表示的是一个有固定长度的时间窗（长度为lag），这个时间窗是随时间而不断移动的。所以，副节点上的读事务会一直等到副节点对replication stream的重演充分赶上主节点之后才开始，也就是说，直到副节点所重演的事务落在长度为lag的时间窗口之内时，或者来自主节点上的heartbeat表示副节点已经赶上主节点时，副节点上的读事务才可以开始。如果副节点在规定的时间内（这一时间同样由此策略设置）没有赶上主节点，那么读操作事务将会被放弃。

时间一致性策略可以适用于某些网页应用中。在这些应用中，可以使滞后时间小于用户访问一序列的网页时的交互时间。

在给定的负载和可用的硬件资源情况下，如果将滞后时间设置得过短，会导致经常性的超时异常，从而会降低副节点的读操作可用性。过短的滞后时间同样会增加读操作请求的等待时间，因为副节点会让读事务一直等待，直到它能在replication stream中赶上主节点。应用程序的设计者应该需要从应用程序的角度来决定可以接受的最长滞后时间，然后用这个时间来配置时间一致性策略。

提交点一致性策略（Commit Point Consistency Policy）

这个策略以副节点在replication stream上所处的位置来定义滞后时间，这个位置与某个特定的事务的提交点相关。这个策略保证，在副节点上的读操作可以开始之前，replication stream上所有在提交点之前出现的事务，包括处于提交点的事务，都将被副节点重演。这种情况下的滞后表示了一个可扩大的事务更新窗口，窗口的下端固定在提交点，而窗口上端可以随着新事务在主节点上的提交而扩大。JE HA扩展了事务的API，从而使应用程序可以得到与某事务的提交点。

和时间一致性策略一样，如果副节点在该策略规定的时间内没有重演提交点所限定的事务，那么副节点上的读操作事务会被放弃。

提交点一致性策略可以为网页应用提供会话一致性（session consistency）。通过将一个提交点和用户的会话相关联，并且在会话的每一个写操作中更新提交点，这样便可以实现会话的一致性。会话中的读事务可以利用提交点一致性策略来保证所有的读事务都可以读到会话所写入的数据，而无论该读操作是发生在哪个副节点上。

由于需要应用程序在读写操作过程中维护提交点的状态，所以提交点一致性的使用会比时间一致性复杂。时间一致性相对来说比较简单，但是它对时间的依赖意味着，当主节点、副节点或者网络负载过高时，这一策略不一定能正确地实施。

性能

由于JE HA 以JE为基础，因此所有适用于JE的性能调优方法都适用于JE HA。除此之外，还有一些专门针对JE HA的调优。以下章节将进行详细说明。

持久性

持久性配置对应用程序的写操作性能调优来说是最重要的方面之一。在不支持replication的JE环境中持久性的缺省设置是SYNC，这样可以保证已提交的事务在机器发生故障时不会被丢失。虽然SYNC设置通常会导致较大的性能损失，但为了保证数据在事务提交之后可以永久保留在磁盘上，这种设置是必要的。

对基于JE HA的应用程序的调优，把持久性设置成，NO_SYNC和SIMPLE_MAJORITY是一个较好的着手点。这个设置可以允许主节点和副节点异步地向文件系统和磁盘写入数据，也就是在提交之后的某个时间点才写入磁盘，而不是在提交后马上同步写入文件系统和磁盘。此外，当向磁盘存储数据时，JE可以对多个事务产生的更新进行打包，从而形成条数较少的，体积较大的，然而效率会更高的顺序写操作。

把提交响应策略设置成SIMPLE_MAJORITY可以减少主节点等待提交响应所带来的延迟时间，因为这种延迟不受性能最差的副节点所决定。对节点数目较大的replication group来说，延迟时间会随着节点数目的增大而延长。采用SIMPLE_MAJORITY设置可以保证万一当前的主节点发生故障时，数据在其他副节点中是可用的。但是有一种情况例外：即同时有多个程序发生故障从而导致过半数的节点（这些节点将会产生提交响应）在事务提交之后并且在将数据存储到磁盘之前发生宕机。这时候主节点会由于接收不到过半数的节点发来的提交响应而进行无限期等待。

从这种持久性设置开始着手调优，程序设计者可以为程序的整体需求选择最好的持久性等级。值得注意的是，持久性可以在事务级别上进行设置。这样可以允许一个程序的不同部分根据本地的需求使用不同级别的持久性。

读一致性

为了能有效利用副节点上的读操作吞吐量，并且能使主节点上的负载达到最小（因为只有主节点才能进行写操作），所有不要求绝对一致性的读操作请求都应该由应用程序路由到副节点上。并且，为了使延迟达到最小，可以在满足应用程序需求的条件下选择最不严格的一致性策略。

和持久性一样，可以在单独的事务级别上设置一致性。在之前的章节中，已经详细说明了如何选择和设置一致性策略。

Replication stream的代价

JE HA利用TCP协议从主节点向副节点传输replication stream。在一个有N个节点的replication group中，一共有（最后肯定会有）N-1份日志拷贝在网络中传输。因此在设计数据模型时，对键（key）所占空间大小进行优化会对性能有所帮助。特别是对写密集型的应用程序来说，这一点尤其重要。

值得注意的是，正如写操作性能的瓶颈往往是连续写磁盘的吞吐量，网络的吞吐量也正是replication性能的瓶颈。因此，重要的是要确保可利用的网络带宽能够负担预期的写负载。

副节点的滞后

当主节点需要向副节点发送最新的日志条目时，由于最新的日志条目很有可能存储在主节点的缓存中，从而不需要访问磁盘，因此主节点上的缓存能有助于主节点高效地构造replication stream。如果需要访问磁盘来获得旧的日志条目，则会导致与正在进行的所有磁盘写操作（这些写操作会在磁盘存储新的日志条目）发生竞争。这种读/写磁盘的竞争会扰乱顺序写磁盘的模式，而这种模式正是JE能保证较高写操作性能的关键。

因此，最好能保证所有的节点处在运行状态，这样副节点可以和主节点的保持一致，主机点将不用频繁通过访问磁盘来构建replication stream。如果某个副节点发生故障，则应尽快让它恢复运行。

如果某个节点（假设是节点A）发生故障，某些日志文件尽管已经被清除器（cleaner）回收，但是这些日志对节点A来说是其恢复运行后构建replication stream所必需的，那么JE HA将会阻止replication group中其他活动节点删除这些日志文件。JE HA只会在某段时间（这个时间是可设置的）之内阻止对这些日志文件的删除。在这段时间内，日志文件将会在活动节点中不断堆积，导致活动节点存在磁盘空间耗尽的风险。如果节点A在这段时间之后（磁盘空间已经耗尽）重新运行，那么有可能任何一个活动节点中都不存在一个连续的replication stream。因此，这种情况下节点A需要进行网络恢复（Network Restore）操作。网络恢复操作将某个活动节点中的日志文件复制到节点A中，然后在节点A中开始重演主节点发送过来的replication stream。如果数据库环境比较大，网络恢复操作则有可能是磁盘读/写密集型和网络传输密集型操作。

JE HA的可扩展性

JE HA架构支持单节点写和多节点读。下面的章节将分别描述读操作和写操作的扩展。

写扩展性

对于单节点写来说，写操作的可扩展性主要由主节点处理写操作的能力所决定，继而又取决于主节点上可用的硬件资源。通过使用提交到网络这种持久性策略，以及通过降低那些不需要绝对一致性的读操作的负荷，主节点可以降低某些I/O负载。

在当前的实现中，主节点负责维护发送到其他所有成员节点的replication stream。每个replication stream的构建都会在主节点上增加CPU负载。为了改进这个问题，每个replication stream都将由一个专门的feeder线程来维护，这个feeder线程可以利用多核机器的优势来维护并行的replication stream。每个replication stream同样会给主节点所在的子网带来网络传输负载，并且写密集型的应用程序对带宽的需求有可能会超出子网上可用的网络带宽。

写分区（partition）

如果应用程序的需求允许，写操作的水平扩展性可以通过将数据分区到多个支持replication的环境中实现。但是JE HA目前没有提供明确的API来支持这种数据分区。

下图描述了如何利用三个支持replication的环境来对数据进行分区：RE1，RE2和RE3对应着三个replication groups，G1，G2以及G3。数据既可以均匀地分布在三个组中，也可以基于预期的写/更新频率来进行分区。例子中的每个replication group由三个可选节点以及一个监测节点组成。这几个replication groups分布在三台机器中MC1，MC2以及MC3。

这个例子里的路由器包含三个监测节点：G1（M），G2（M）以及G3（M），每个监测节点对应一个replication group。路由器必须根据数据分区规则来将数据操作请求路由到特定的节点中。这些路由方式都取决于要访问的数据本身以及操作的类型（读或写）。

（图五）HA写分区：3个写分区，3个replication groups，每个replication group有3个可选节点。

读扩展性

JE HA中读扩展性可以通过多个只读副节点来实现。JE HA并没有对replication group中节点的数目有所限制。添加一个新的节点并不会增加当前的replication group对资源的需求。但是正如上文所描述一样，添加新节点会增加写节点（即主节点）以及网络的负载。

通过添加新节点来提高读扩展性对于应用程序来说是完全透明的。一个新节点可以被添加进一个正在运行的replication group中，并且一旦这个新节点在本地拥有足够多的日志副本，新节点便可以开始处理读操作请求。

结语

JE HA通过简单、直接地扩展JE的API来提供快捷、可靠以及可扩展的数据管理功能，并且能够嵌入到应用程序当中。JE HA的配置是十分灵活的，允许用户在数据持久性、数据一致性以及性能等方面综合权衡之后，设计出具有广泛适用范围的应用程序。

你可以在以下网址下载Oracle Berkeley DB Java版本：

http://www.oracle.com/technology/software/products/berkeley-db/je/index.html

你可以在Oracle Technology Network（OTN）上提交你对Oracle Berkeley DB Java版本的意见或者问题：

http://forums.oracle.com/forums/forum.jspa?forumID=273

关于销售或者产品支持的信息，请发送Email：berkeleydb-info_us@oracle.com

想了解关于新产品发布信息，请发送Email：bdb-join@oss.oracle.com

1.下载JE

用户可以到官方网址http://www.oracle.com/technology/software/products/berkeley-db/je/index.html下载最新的JE版本，本文使用的是JE 4.0.71. 同时，您也可以到http://www.oracle.com/technology/documentation/berkeley-db/je/examples/je/rep/quote/package-summary.html参考示例的详细英文文档。

2.编译示例

请确认您在编译示例之前已经安装好JDK，如果您的机器上没有安装，请到http://java.sun.com下载JDK。

用户下载示例后，解压缩到当前目录，你会发现一个je-4.0.71的目录，进入该目录，您会在lib目录下发现JE的jar包，HA的示例代码存放在examples/je/rep/quote目录下。将lib下的je-4.0.71.jar拷贝到examples/je/rep/quote下，打开命令行，进入到当前目录，输入如下命令：javac -cp .;je-4.0.71.jar *.java，该目录下的所有java文件都会被编译成class文件。

3.示例代码概述

JE-HA的示例代码分为三种：

• StockQuotes：该示例代码是一个最基本的使用JE-HA应用程序的展示，其主要目的是让您对JE-HA的基本概念有一个了解，并演示了如何使用JE-HA的API创建一个ReplicatedEnvironment和处理读写事务。
• RouterDrivenStockQuotes和HARouter：RouterDriverStockQuotes以StockQuotes为基础，展示了如何使用JE Monitor（HARouter）根据应用程序请求的类别（读或写）和结点的状态（Master或Replica），指引请求到正确的结点。该示例的目的是演示如何将负载平衡器与JE-HA结合起来，在该示例中，HARouter扮演负载平衡器的角色。
• UpdateForwardingStockQuote和SimpleRouter：UpdateForwardingStockQuote以RouterDrivenStockQuotes为基础，与HARouter不同，SimpleRouter并不关心应用程序的请求类别和结点的状态，只是简单的将请求转发给它所知道的结点，而UpdateForwardingStockQuote使用了StateChangeListener来跟踪当前的Master结点，并将写请求转发给Master，自己处理读请求。这个示例的目的是演示如何将一个负载平衡器嵌入到JE-HA的框架中。

本文主要演示如何运行前两个示例，第三个示例的运行方法与第二个基本类似，在这里就不做详细介绍了。

4.创建运行环境

为了演示的方便（截图的原因），我在同一台机器上运行三个HA结点。在开始运行示例代码之前，需要创建每个结点的environment home目录。这里，我在examples目录下创建三个目录，分别为：rep1，rep2，rep3。

因为JE-HA示例代码的包是je.rep.quote，所以命令行需要在examples目录下运行。

5.运行StockQuotes示例

(1).启动三个结点，如下图所示：

(2).在Master上写数据，在Replica上读取数据，如下图所示：

（3). 如果在Replica上写数据。由于JE-HA只允许在Master上写数据，因此该操作是非法的，控制台会打印出提示信息，如下图红框内所示：

(4).将Master关闭，JE-HA会在当前集群中重新选举出一个新的Master，只有现存的Replica的数目符合选举策略，如下图红框内所示，node3被选举成为新的Master：

(5).将剩下的Replica也关掉，只剩下Master，这种情况下，应用程序还可以在Master上正常读取数据，如果进行写数据操作，写操作可以提交，但是会抛出InsufficientReplicasException异常。这是因为示例的默认事务提交策略是要得到超过半数的Replica的回应的，但是当前没有任何活跃的Replica，所以虽然写操作提交成功，但同时会抛出异常信息。如下两图所示：

6.运行RouterDrivenStockQuotes和HARouter示例

运行RouterDrivenStockQuotes和HARouter示例与运行StockQuotes示例基本类似，唯一的不同是需要在启动三个RouterDrivenStockQuotes之外再启动一个HARouter。

(1).启动整个HA组，如下图所示：

(2).HARouter指引写请求到Master，如下图所示：

(3).HARouter将读请求指引到目前空闲的结点，如下图所示：

(4).关闭当前的Master，HARouter会自动找到新选出来的Master，如下图所示：

(5).当所有Replica都关闭，只剩下Master还活跃的时候，HARouter会提示写请求是非法的（原因在StockQuotes演示第六步已经介绍了），如下图所示：

7.总结

JE-HA是对JE功能的一个巨大提升。希望本文能够让你更好的了解并使用JE-HA。如果您对本文有什么意见或对JE-HA有什么建议，请您站内留言。

 memset(&setup_info, 0, sizeof(SETUP_DATA));
 setup_info.progname = progname;
 memset(&my_app_data, 0, sizeof(APP_DATA));
 dbenv = NULL;
 ret = 0;
 /*
  * 默认使用选举的方法选出master。替代方案就是指定某一个site是master，
  * 其他site是replica。
  */
 start_policy = DB_REP_ELECTION;

 /* 创建一个拥有replication功能的数据库环境，但还不打开。 */
 if ((ret = create_env(progname, &dbenv)) != 0)
  goto err;
 dbenv->app_private = &my_app_data;

 /*
  * 配置replication消息处理回调函数。
  * 有任何replication消息，Berkeley DB都会调用该函数来处理。
  */
 (void)dbenv->set_event_notify(dbenv, event_callback);

 /* Parse command line and perform common replication setup. */
 if ((ret = common_rep_setup(dbenv, argc, argv, &setup_info)) != 0)
  goto err;

 /*
  * Perform repmgr-specific setup based on command line options.
  * 如果显式指定了master，那么就使用DB_REP_MASTER把本site设置为master，
  * 并用DB_REP_CLIENT把其他site设置为replica。
  */
 if (setup_info.role == MASTER)
  start_policy = DB_REP_MASTER;
 else if (setup_info.role == CLIENT)
  start_policy = DB_REP_CLIENT;
 /*
  * 设置本地site信息，也就是IP地址和端口信息。因为site是一个
  * （数据库环境，IP地址，port）的三元组，而数据库环境我们已经创建好
  * 了。
  */
 if ((ret = dbenv->repmgr_set_local_site(dbenv, setup_info.self.host,
     setup_info.self.port, 0)) != 0) {
  fprintf(stderr, “Could not set listen address (%d).\n”, ret);
  goto err;
 }
 site_list = setup_info.site_list;
 /*
  * 添加其他site的信息到本site。如果显式指定master，那么一个replica
  * 一定要知道master的信息；如果选举，那么每一个site要知道其他所有
  * site的信息。
  *
  * 两个site可以成为peer关系，通过在下面的函数中设置
  * DB_REPMGR_PEER来指定。一个replica可以被它的peer更新到最新，这样
  * 就为master去掉了更新过时的replica的负担。
  */
 for (i = 0; i < setup_info.remotesites; i++) {
  if ((ret = dbenv->repmgr_add_remote_site(dbenv,
      site_list[i].host, site_list[i].port, NULL,
      site_list[i].peer ? DB_REPMGR_PEER : 0)) != 0) {
   dbenv->err(dbenv, ret,
       “Could not add site %s:%d”, site_list[i].host,
       (int)site_list[i].port);
   goto err;
  }
 }

 /*
  * Configure heartbeat timeouts so that repmgr monitors the
  * health of the TCP connection.  Master sites broadcast a heartbeat
  * at the frequency specified by the DB_REP_HEARTBEAT_SEND timeout.
  * Client sites wait for message activity the length of the
  * DB_REP_HEARTBEAT_MONITOR timeout before concluding that the
  * connection to the master is lost.  The DB_REP_HEARTBEAT_MONITOR
  * timeout should be longer than the DB_REP_HEARTBEAT_SEND timeout.
  */
 if ((ret = dbenv->rep_set_timeout(dbenv, DB_REP_HEARTBEAT_SEND,
     5000000)) != 0)
  dbenv->err(dbenv, ret,
      “Could not set heartbeat send timeout.\n”);
 if ((ret = dbenv->rep_set_timeout(dbenv, DB_REP_HEARTBEAT_MONITOR,
     10000000)) != 0)
  dbenv->err(dbenv, ret,
      “Could not set heartbeat monitor timeout.\n”);

 /*
  * The following repmgr features may also be useful to your
  * application.  See Berkeley DB documentation for more details.
  *  – Two-site strict majority rule – In a two-site replication
  *    group, require both sites to be available to elect a new
  *    master.
  *  – Timeouts – Customize the amount of time repmgr waits
  *    for such things as waiting for acknowledgements or attempting
  *    to reconnect to other sites.
  *  – Site list – return a list of sites currently known to repmgr.
  */
 /* 打开数据库环境。*/
 if ((ret = env_init(dbenv, setup_info.home)) != 0)
  goto err;

 /* Start checkpoint and log archive threads. */
 sup_args.dbenv = dbenv;
 sup_args.shared = &my_app_data.shared_data;
 if ((ret = start_support_threads(dbenv, &sup_args, &ckp_thr,
     &lga_thr)) != 0)
  goto err;

 if ((ret = dbenv->repmgr_start(dbenv, 3, start_policy)) != 0)
  goto err;

 if ((ret = doloop(dbenv, &my_app_data.shared_data)) != 0) {
  dbenv->err(dbenv, ret, “Client failed”);
  goto err;
 }

 /* Finish checkpoint and log archive threads. */
 if ((ret = finish_support_threads(&ckp_thr, &lga_thr)) != 0)
  goto err;

 /*
  * We have used the DB_TXN_NOSYNC environment flag for improved
  * performance without the usual sacrifice of transactional durability,
  * as discussed in the “Transactional guarantees” page of the Reference
  * Guide: if one replication site crashes, we can expect the data to
  * exist at another site.  However, in case we shut down all sites
  * gracefully, we push out the end of the log here so that the most
  * recent transactions don’t mysteriously disappear.
  */
 if ((ret = dbenv->log_flush(dbenv, NULL)) != 0) {
  dbenv->err(dbenv, ret, “log_flush”);
  goto err;
 }

err:
 if (dbenv != NULL &&
     (t_ret = dbenv->close(dbenv, 0)) != 0) {
  fprintf(stderr, “failure closing env: %s (%d)\n”,
      db_strerror(t_ret), t_ret);
  if (ret == 0)
   ret = t_ret;
 }

 return (ret);
}

/*
 * 事件通知函数。当使用replication manager的时候，该事件已经被
 * replication manager 适当地处理好了，所以在这个回调函数当中，
 * 我们只需要简单地更新状态或者打印消息即可。
 */
static void
event_callback(dbenv, which, info)
 DB_ENV *dbenv;
 u_int32_t which;
 void *info;
{
 APP_DATA *app = dbenv->app_private;
 SHARED_DATA *shared = &app->shared_data;

 info = NULL;    /* Currently unused. */

 switch (which) {
 case DB_EVENT_REP_CLIENT:
  shared->is_master = 0;
  shared->in_client_sync = 1;
  break;

 case DB_EVENT_REP_MASTER:
  shared->is_master = 1;
  shared->in_client_sync = 0;
  break;

 case DB_EVENT_REP_NEWMASTER:
  shared->in_client_sync = 1;
  break;

 case DB_EVENT_REP_PERM_FAILED:
  /*
   * Did not get enough acks to guarantee transaction
   * durability based on the configured ack policy.  This
   * transaction will be flushed to the master site’s
   * local disk storage for durability.
   */
  printf(
    “Insufficient acknowledgements to guarantee transaction durability.\n”);
  break;

 case DB_EVENT_REP_STARTUPDONE:
  shared->in_client_sync = 0;
  break;

 default:
  dbenv->errx(dbenv, “ignoring event %d”, which);
 }
}

got_self = is_repmgr = maxsites = ret = site.peer = 0;

/*
* 站点的优先级。在选举的时候，如果多个站点具有最新的日志，那么
* 优先级最高的站点成为master。所以，应该把后备做master的站点
* 设置更高的优先级。
*/
priority = 100;

/*
* 持久消息(permanent message, i.e. commit/abort/checkpoint日志)
* 确认策略。repmgr要求replica根据持久消息做相同的动作
* (commit/abort/checkpoint)，然后对持久消息进行确认。repmgr等待一定
* 数目的replica确认，这个数目字这里设置。
*/
ack_policy = DB_REPMGR_ACKS_QUORUM;
setup_info->role = UNKNOWN;
if (strncmp(setup_info->progname, “ex_rep_mgr”, 10) == 0)
is_repmgr = 1;

/*
* Replication setup calls that are only needed if a command
* line option is specified are made within this while/switch
* statement.  Replication setup calls that should be made
* whether or not a command line option is specified are after
* this while/switch statement.
*/
while ((ch = getopt(argc, argv, “a:bCh:l:Mn:p:R:r:v”)) != EOF) {
switch (ch) {
case ‘a’:
if (!is_repmgr)
usage(is_repmgr, setup_info->progname);
if (strncmp(optarg, “all”, 3) == 0)
ack_policy = DB_REPMGR_ACKS_ALL;
/* repmgr等待所有站点的持久消息确认。*/
else if (strncmp(optarg, “quorum”, 6) != 0)
usage(is_repmgr, setup_info->progname);
break;
case ‘b’:
/*
* 批量传输设置。在bulk buffer满了或者有了持久消息
* (permanent message)的时候才传输所有的消息。
* Configure bulk transfer to send groups of records
* to clients in a single network transfer.  This is
* useful for master sites and clients participating
* in client-to-client synchronization.
*/
if ((ret = dbenv->rep_set_config(dbenv,
DB_REP_CONF_BULK, 1)) != 0) {
dbenv->err(dbenv, ret,
“Could not configure bulk transfer.\n”);
goto err;
}
break;
case ‘C’:
setup_info->role = CLIENT;
break;
case ‘h’:
setup_info->home = optarg;
break;
case ‘l’:
setup_info->self.host = strtok(optarg, “:”);
if ((portstr = strtok(NULL, “:”)) == NULL) {
fprintf(stderr, “Bad host specification.\n”);
goto err;
}
setup_info->self.port = (unsigned short)atoi(portstr);
setup_info->self.peer = 0;
got_self = 1;
break;
case ‘M’:
setup_info->role = MASTER;
break;
case ‘n’:
setup_info->nsites = atoi(optarg);
/*
* For repmgr, set the total number of sites in the
* replication group.  This is used by repmgr internal
* election processing.  For base replication, nsites
* is simply passed back to main for use in its
* communications and election processing.
*/
if (is_repmgr && setup_info->nsites > 0 &&
(ret = dbenv->rep_set_nsites(dbenv,
setup_info->nsites)) != 0) {
dbenv->err(dbenv, ret,
“Could not set nsites.\n”);
goto err;
}
break;
case ‘p’:
priority = atoi(optarg);
break;
case ‘R’:
if (!is_repmgr)
usage(is_repmgr, setup_info->progname);
site.peer = 1; /* FALLTHROUGH */
case ‘r’:
site.host = optarg;
site.host = strtok(site.host, “:”);
if ((portstr = strtok(NULL, “:”)) == NULL) {
fprintf(stderr, “Bad host specification.\n”);
goto err;
}
site.port = (unsigned short)atoi(portstr);
if (setup_info->site_list == NULL ||
setup_info->remotesites >= maxsites) {
maxsites = maxsites == 0 ? 10 : 2 * maxsites;
if ((setup_info->site_list =
realloc(setup_info->site_list,
maxsites * sizeof(repsite_t))) == NULL) {
fprintf(stderr, “System error %s\n”,
strerror(errno));
goto err;
}
}
(setup_info->site_list)[(setup_info->remotesites)++] =
site;
site.peer = 0;
break;
case ‘v’:
if ((ret = dbenv->set_verbose(dbenv,
DB_VERB_REPLICATION, 1)) != 0)
goto err;
break;
case ‘?’:
default:
usage(is_repmgr, setup_info->progname);
}
}

/* Error check command line. */
if (!got_self || setup_info->home == NULL)
usage(is_repmgr, setup_info->progname);
if (!is_repmgr && setup_info->role == UNKNOWN) {
fprintf(stderr, “Must specify -M or -C.\n”);
goto err;
}

/*
* Set replication group election priority for this environment.
* An election first selects the site with the most recent log
* records as the new master.  If multiple sites have the most
* recent log records, the site with the highest priority value
* is selected as master.
*/
if ((ret = dbenv->rep_set_priority(dbenv, priority)) != 0) {
dbenv->err(dbenv, ret, “Could not set priority.\n”);
goto err;
}

/*
* 设置持久消息确认策略。
* For repmgr, set the policy that determines how master and client
* sites handle acknowledgement of replication messages needed for
* permanent records.  The default policy of “quorum” requires only
* a quorum of electable peers sufficient to ensure a permanent
* record remains durable if an election is held.  The “all” option
* requires all clients to acknowledge a permanent replication
* message instead.
*/
if (is_repmgr &&
(ret = dbenv->repmgr_set_ack_policy(dbenv, ack_policy)) != 0) {
dbenv->err(dbenv, ret, “Could not set ack policy.\n”);
goto err;
}

/*
* Set the threshold for the minimum and maximum time the client
* waits before requesting retransmission of a missing message.
* Base these values on the performance and load characteristics
* of the master and client host platforms as well as the round
* trip message time.
* 设置丢失的日志消息的重传时限。如果Berkeley DB发现有日志消息丢失，
* 比如它发现连续收到的两条日志消息并不连续，它会在等待20秒后请求
* 重传这条日志消息，如果仍然没有收到，它会加倍等待的时间，直到该
* 等待时间达到500秒。
*
* 在使用repmgr的时候，由于使用了TCP/IP协议，不可能丢失消息，
* 所以可以不设置；如果使用不可靠的传输协议比如udp，那么可以通过
* 设置这个时限，确保能够收到丢失的日志消息。也就是说，Berkeley DB
* 内部实现了一个确保不可靠传输协议可靠地传输数据的协议，这样如果
* 我们使用UDP协议来传输Berkeley DB replication消息，那么丢包和
* 包错序不会影响Berkeley DB replication 的正常工作。
*/
if ((ret = dbenv->rep_set_request(dbenv, 20000, 500000)) != 0) {
dbenv->err(dbenv, ret,
“Could not set client_retransmission defaults.\n”);
goto err;
}

/*
* Configure deadlock detection to ensure that any deadlocks
* are broken by having one of the conflicting lock requests
* rejected. DB_LOCK_DEFAULT uses the lock policy specified
* at environment creation time or DB_LOCK_RANDOM if none was
* specified.
*/
if ((ret = dbenv->set_lk_detect(dbenv, DB_LOCK_DEFAULT)) != 0) {
dbenv->err(dbenv, ret,
“Could not configure deadlock detection.\n”);
goto err;
}

/* The following base replication features may also be useful to your
* application. See Berkeley DB documentation for more details.
*   – Master leases: Provide stricter consistency for data reads
*     on a master site.
*   – Timeouts: Customize the amount of time Berkeley DB waits
*     for such things as an election to be concluded or a master
*     lease to be granted.
*   – Delayed client synchronization: Manage the master site’s
*     resources by spreading out resource-intensive client
*     synchronizations.
*   – Blocked client operations: Return immediately with an error
*     instead of waiting indefinitely if a client operation is
*     blocked by an ongoing client synchronization.
*/

err:
return (ret);
}

static int
print_stocks(dbp)
DB *dbp;
{
DBC *dbc;
DBT key, data;
#define MAXKEYSIZE 10
#define MAXDATASIZE 20
char keybuf[MAXKEYSIZE + 1], databuf[MAXDATASIZE + 1];
int ret, t_ret;
u_int32_t keysize, datasize;

/* 读取数据，打印数据库当中所有记录。这个函数可以在master和每一个
* replica上面执行。*/
if ((ret = dbp->cursor(dbp, NULL, &dbc, 0)) != 0) {
dbp->err(dbp, ret, “can’t open cursor”);
return (ret);
}

memset(&key, 0, sizeof(key));
memset(&data, 0, sizeof(data));

printf(“\tSymbol\tPrice\n”);
printf(“\t======\t=====\n”);
/* 无论master上面还是replica上面，都是用完全相同的方法读取数据。*/
for (ret = dbc->get(dbc, &key, &data, DB_FIRST);
ret == 0;
ret = dbc->get(dbc, &key, &data, DB_NEXT)) {
keysize = key.size > MAXKEYSIZE ? MAXKEYSIZE : key.size;
memcpy(keybuf, key.data, keysize);
keybuf[keysize] = ‘\0′;

datasize = data.size >= MAXDATASIZE ? MAXDATASIZE : data.size;
memcpy(databuf, data.data, datasize);
databuf[datasize] = ‘\0′;

printf(“\t%s\t%s\n”, keybuf, databuf);
}
printf(“\n”);
fflush(stdout);

if ((t_ret = dbc->close(dbc)) != 0 && ret == 0)
ret = t_ret;

switch (ret) {
case 0:
case DB_NOTFOUND:
case DB_LOCK_DEADLOCK:
return (0);
default:
return (ret);
}
}

/* Start checkpoint and log archive support threads. */
int
start_support_threads(dbenv, sup_args, ckp_thr, lga_thr)
DB_ENV *dbenv;
supthr_args *sup_args;
thread_t *ckp_thr;
thread_t *lga_thr;
{
int ret;

ret = 0;
if ((ret = thread_create(ckp_thr, NULL, checkpoint_thread,
sup_args)) != 0) {
dbenv->errx(dbenv, “can’t create checkpoint thread”);
goto err;
}
if ((ret = thread_create(lga_thr, NULL, log_archive_thread,
sup_args)) != 0)
dbenv->errx(dbenv, “can’t create log archive thread”);
err:
return (ret);

}

/* Wait for checkpoint and log archive support threads to finish. */
int
finish_support_threads(ckp_thr, lga_thr)
thread_t *ckp_thr;
thread_t *lga_thr;
{
void *ctstatus, *ltstatus;
int ret;

ret = 0;
if (thread_join(*lga_thr, &ltstatus) ||
thread_join(*ckp_thr, &ctstatus)) {
ret = -1;
goto err;
}
if ((uintptr_t)ltstatus != EXIT_SUCCESS ||
(uintptr_t)ctstatus != EXIT_SUCCESS)
ret = -1;
err:
return (ret);
}

#define BUFSIZE 1024

int
doloop(dbenv, shared_data)
DB_ENV *dbenv;
SHARED_DATA *shared_data;
{
DB *dbp;
DBT key, data;
char buf[BUFSIZE], *first, *price;
u_int32_t flags;
int ret;

dbp = NULL;
ret = 0;
memset(&key, 0, sizeof(key));
memset(&data, 0, sizeof(data));

for (;;) {
printf(“QUOTESERVER%s> “,
shared_data->is_master ? “” : ” (read-only)”);
fflush(stdout);

if (fgets(buf, sizeof(buf), stdin) == NULL)
break;

#define DELIM ” \t\n”
if ((first = strtok(&buf[0], DELIM)) == NULL) {
/* Blank input line. */
price = NULL;
} else if ((price = strtok(NULL, DELIM)) == NULL) {
/* Just one input token. */
if (strncmp(buf, “exit”, 4) == 0 ||
strncmp(buf, “quit”, 4) == 0) {
/*
* This makes the checkpoint and log
* archive threads stop.
*/
shared_data->app_finished = 1;
break;
}
dbenv->errx(dbenv, “Format: TICKER VALUE”);
continue;
} else {
/* Normal two-token input line. */
if (first != NULL && !shared_data->is_master) {
dbenv->errx(dbenv, “Can’t update at client”);
continue;
}
}

if (dbp == NULL) {
if ((ret = db_create(&dbp, dbenv, 0)) != 0)
return (ret);

flags = DB_AUTO_COMMIT;
/*
* Open database with DB_CREATE only if this is
* a master database.  A client database uses
* polling to attempt to open the database without
* DB_CREATE until it is successful. 由于数据库
* 的创建也是一个写入操作，所以，replica不应该自
* 己创建数据库，而是定期检查是否有数据库被创建
* 好。当master创建了数据库后，这个日志消息会到
* 达所有的replica上面，于是Berkeley DB的
* replication功能自动创建好这个数据库。
*
* This DB_CREATE polling logic can be simplified
* under some circumstances.  For example, if the
* application can be sure a database is already
* there, it would never need to open it with
* DB_CREATE.
*/
if (shared_data->is_master)
flags |= DB_CREATE;
if ((ret = dbp->open(dbp,
NULL, DATABASE, NULL, DB_BTREE, flags, 0)) != 0) {
if (ret == ENOENT) {
printf(
“No stock database yet available.\n”);
if ((ret = dbp->close(dbp, 0)) != 0) {
dbenv->err(dbenv, ret,
“DB->close”);
goto err;
}
dbp = NULL;
continue;
}
if (ret == DB_REP_HANDLE_DEAD ||
ret == DB_LOCK_DEADLOCK) {
dbenv->err(dbenv, ret,
“please retry the operation”);
dbp->close(dbp, DB_NOSYNC);
dbp = NULL;
continue;
}
dbenv->err(dbenv, ret, “DB->open”);
goto err;
}
}

if (first == NULL) {
/*
* If this is a client in the middle of
* synchronizing with the master, the client data
* is possibly stale and won’t be displayed until
* client synchronization is finished.  It is also
* possible to display the stale data if this is
* acceptable to the application.
*/
if (shared_data->in_client_sync)
printf(
“Cannot read data during client synchronization – please try again.\n”);
else
switch ((ret = print_stocks(dbp))) {
case 0:
break;
case DB_REP_HANDLE_DEAD:
(void)dbp->close(dbp, DB_NOSYNC);
dbp = NULL;
break;
default:
dbp->err(dbp, ret,
“Error traversing data”);
goto err;
}
} else {
key.data = first;
key.size = (u_int32_t)strlen(first);

data.data = price;
data.size = (u_int32_t)strlen(price);

if ((ret = dbp->put(dbp,
NULL, &key, &data, DB_AUTO_COMMIT)) != 0) {
dbp->err(dbp, ret, “DB->put”);
goto err;
}
}
}

err: if (dbp != NULL)
(void)dbp->close(dbp, DB_NOSYNC);
return (ret);
}

int
create_env(progname, dbenvp)
const char *progname;
DB_ENV **dbenvp;
{
DB_ENV *dbenv;
int ret;

if ((ret = db_env_create(&dbenv, 0)) != 0) {
fprintf(stderr, “can’t create env handle: %s\n”,
db_strerror(ret));
return (ret);
}

dbenv->set_errfile(dbenv, stderr);
dbenv->set_errpfx(dbenv, progname);

*dbenvp = dbenv;
return (0);
}

/* Open and configure an environment. */
int
env_init(dbenv, home)
DB_ENV *dbenv;
const char *home;
{
u_int32_t flags;
int ret;

(void)dbenv->set_cachesize(dbenv, 0, CACHESIZE, 0);
(void)dbenv->set_flags(dbenv, DB_TXN_NOSYNC, 1);

flags = DB_CREATE | DB_INIT_LOCK | DB_INIT_LOG | DB_INIT_MPOOL |
DB_INIT_REP | DB_INIT_TXN | DB_RECOVER | DB_THREAD;
if ((ret = dbenv->open(dbenv, home, flags, 0)) != 0)
dbenv->err(dbenv, ret, “can’t open environment”);
return (ret);
}

/*
* In this application, we specify all communication via the command line.  In
* a real application, we would expect that information about the other sites
* in the system would be maintained in some sort of configuration file.  The
* critical part of this interface is that we assume at startup that we can
* find out
* 1) what host/port we wish to listen on for connections,
* 2) a (possibly empty) list of other sites we should attempt to connect
* to; and
* 3) what our Berkeley DB home environment is.
*
* These pieces of information are expressed by the following flags.
* -a all|quorum (optional; repmgr only, a stands for ack policy)
* -b (optional, b stands for bulk)
* -C or -M start up as client or master (optional for repmgr, required
*      for base example)
* -h home directory (required)
* -l host:port (required; l stands for local)
* -n nsites (optional; number of sites in replication group; defaults to 0
* in which case we try to dynamically compute the number of sites in
* the replication group)
* -p priority (optional: defaults to 100)
* -r host:port (optional; r stands for remote; any number of these may be
* specified)
* -R host:port (optional; repmgr only, remote peer)
* -v (optional; v stands for verbose)
*/
void
usage(is_repmgr, progname)
const int is_repmgr;
const char *progname;
{
fprintf(stderr, “usage: %s “, progname);
if (is_repmgr)
fprintf(stderr, “[-CM]-h home -l host:port[-r host:port]%s%s”,
“[-R host:port][-a all|quorum][-b][-n nsites]“,
“[-p priority][-v]\n”);
else
fprintf(stderr, “-CM -h home -l host:port[-r host:port]%s”,
“[-b][-n nsites][-p priority][-v]\n”);
exit(EXIT_FAILURE);
}

/*
* This is a very simple thread that performs checkpoints at a fixed
* time interval.  For a master site, the time interval is one minute
* plus the duration of the checkpoint_delay timeout (30 seconds by
* default.)  For a client site, the time interval is one minute.
*/
void *
checkpoint_thread(args)
void *args;
{
DB_ENV *dbenv;
SHARED_DATA *shared;
supthr_args *ca;
int i, ret;

ca = (supthr_args *)args;
dbenv = ca->dbenv;
shared = ca->shared;

for (;;) {
/*
* Wait for one minute, polling once per second to see if
* application has finished.  When application has finished,
* terminate this thread.
*/
for (i = 0; i < 60; i++) {
sleep(1);
if (shared->app_finished == 1)
return ((void *)EXIT_SUCCESS);
}

/* Perform a checkpoint. */
if ((ret = dbenv->txn_checkpoint(dbenv, 0, 0, 0)) != 0) {
dbenv->err(dbenv, ret,
“Could not perform checkpoint.\n”);
return ((void *)EXIT_FAILURE);
}
}
}

/*
* This is a simple log archive thread.  Once per minute, it removes all but
* the most recent 3 logs that are safe to remove according to a call to
* DB_ENV->log_archive().
*
* Log cleanup is needed to conserve disk space, but aggressive log cleanup
* can cause more frequent client initializations if a client lags too far
* behind the current master.  This can happen in the event of a slow client,
* a network partition, or a new master that has not kept as many logs as the
* previous master.
*
* The approach in this routine balances the need to mitigate against a
* lagging client by keeping a few more of the most recent unneeded logs
* with the need to conserve disk space by regularly cleaning up log files.
* Use of automatic log removal (DB_ENV->log_set_config() DB_LOG_AUTO_REMOVE
* flag) is not recommended for replication due to the risk of frequent
* client initializations.
*/
void *
log_archive_thread(args)
void *args;
{
DB_ENV *dbenv;
SHARED_DATA *shared;
char **begin, **list;
supthr_args *la;
int i, listlen, logs_to_keep, minlog, ret;

la = (supthr_args *)args;
dbenv = la->dbenv;
shared = la->shared;
logs_to_keep = 3;

for (;;) {
/*
* Wait for one minute, polling once per second to see if
* application has finished.  When application has finished,
* terminate this thread.
*/
for (i = 0; i < 60; i++) {
sleep(1);
if (shared->app_finished == 1)
return ((void *)EXIT_SUCCESS);
}

/* Get the list of unneeded log files. */
if ((ret = dbenv->log_archive(dbenv, &list, DB_ARCH_ABS))
!= 0) {
dbenv->err(dbenv, ret,
“Could not get log archive list.”);
return ((void *)EXIT_FAILURE);
}
if (list != NULL) {
listlen = 0;
/* Get the number of logs in the list. */
for (begin = list; *begin != NULL; begin++, listlen++);
/*
* Remove all but the logs_to_keep most recent
* unneeded log files.
*/
minlog = listlen – logs_to_keep;
for (begin = list, i= 0; i < minlog; list++, i++) {
if ((ret = unlink(*list)) != 0) {
dbenv->err(dbenv, ret,
“logclean: remove %s”, *list);
dbenv->errx(dbenv,
“logclean: Error remove %s”, *list);
free(begin);
return ((void *)EXIT_FAILURE);
}
}
free(begin);
}
}
}