bdb包括对构建基于复制（replication）的高可用性应用程序的支持。bdb replication组由一些独立配置的数据库环境组成。
组里只有一个master数据库环境和一个或多个client环境。Master环境支持读和写，client环境支持只读。如果master环境倒掉了，应用程序将可能提升一个client为新的master。数据库环境可能在单独的计算机上，在单独的硬件分区上（partitions）一个不统一的内存访问系统上，或在一个单独的server的一个磁盘上。唯一的约束就是，replication组的所有的参与者必须在一个字节序（endianness）相同的机器上（都是大数再前或都是小数在前的操作系统）。我们期望这个约束在以后的版本中会去掉。因为总是用bdb环境，任何数量的并发进程或线程可能访问一个数据库环境。在master环境中，多个线程可能读写这个环境。在client环境中，多个线程可能要读这个环境。
应用程序可能被编写成在master和clients间提供不同程度的稳固性。系统能同步的运行以便复制品（replicas）能保证是最新的，对应于所有已提交的事务。但是这样做可能回招致性能上的很大的下降。高性能解决方案有考虑全局的稳固性，允许clients的数据过时一个应用程序可控制的一段时间。
尽管bdb包括必要的构建高可用性数据库环境的底层基础，应用程序仍然必须提供一些鉴定的（critical）组成部分：
应用程序有责任提供通信下部构造。应用程序可能用任何适当的通信协议。例如RPC, TCP/IP, UDP, VI或底板（backplane）消息传递。
应用程序有责任命名。bdb涉及到一个replication组成员的时候是靠一个应用程序提供的id，应用程序必须映射那个id到一个特殊的数据库环境中或通信通道中。
应用程序有责任监视master和clients的状态，和识别任何不可用的（unavailable）数据库环境。应用程序必须提供所有的需要的安全策略。
例如，应用程序可能选择去加密数据，用一个安全的套接层，或什么也不做。
最后，bdb replication实现还有一个附加的特性去增强可靠性。bdb中的replication实现成执行数据库更新用一个不同的编码路径而不是用标
准的。这意味着，有bug的软件的操作可能会毁坏replication master，但不会把clients也毁坏。
Replication和相近的方法的描述：
DB_ENV->rep_elect 举行一个replication竞选
DB_ENV->rep_process_message 处理一个replication消息
DB_ENV->rep_stat Replication统计
DB_ENV->rep_sync Replication同步
Replication 配置：
DB_ENV->rep_set_config 配置replication系统
DB_ENV->rep_start 为replication配置一个环境
DB_ENV->set_rep_limit 限制在响应但个消息时的数据发送
DB_ENV->set_rep_transport 配置replication传输
Replication environment IDs
每个在replication组中的数据库环境必须有一个独一无二的标识符，为它自己和其它replication组中的成员都分配一个不同标识符。这些标识符不必要是全局的，也就是说，每个数据库环境可以分配本地化的标识符给replication组的成员。就是在每数据库环境中都能区分出其他成员就行了，当然全局统一给指定标识符也不为错，只是非必要的。
应用程序有责任去标志每个进来的传递给DB_ENV->rep_process_message的有适当标识符的replication消息。随后，bdb将用这些相同的标识符去标志发送函数发出去的消息。
负标识符被bdb保留使用，不应该被应用程序指定给那些环境。有两个保留的标识符准备给应用程序使用的是：
DB_EID_BROADCAST：指定一个消息应该被广播给所有replication组中的成员。
DB_EID_INVALID：是一个无效的环境id，可能被用于初始化一些环境id变量，那些变量随后被检查合法性。
Replication environment priorities
每个replication组中的数据库环境变量必须有一个优先权，它指定了在replication组中不同环境间的一个相对的顺序。这个顺序在币桓鰉 aster倒掉，在决定选举哪个环境作为新master的时候的一个重要因素。优先权必须是一个非负的整数，但不必要replication组中是独一无二的。优先权为0意味着这个系统永远不能成为一个master，是被忽略的。数越大表示优先权越高，例如，如果一个replication组由3个数据库环境组成，两个由OC3 连接，第三个由T1连接，那么第三个数据库环境就应该被指定一个低点的优先权。
决定哪个client将当选为master时，先看谁有最多的近期的log记录。log记录一样多时，将参考优先权。如果log和优先权一样多时候，将随即
选择一个。
Building replicated applications
最简单的方法去构建一个replicatedbdb应用程序，是首先构建（和调试）这个应用程序的一个事务版本。然后，添加一个薄的replication 层到这个应用程序。所有高可用性应用程序用下面的附加的四个bdb方法：DB_ENV->rep_elect, DB_ENV->rep_process_message, DB_ENV->rep_start 和 DB_ENV->set_rep_transport 还有可能用这个配置方法DB_ENV->set_rep_limit。
DB_ENV->set_rep_transport：配置replication系统的通信底层构造。
DB_ENV->rep_start：配置，或重新配置一个已经存在的数据库环境成为一个master或client.
DB_ENV ->rep_process_message：处理从replication组中别的环境进来的一个消息。对clients来说，它负责接受log 记录和根据master过来的消息更新本地数据库。对master和clients来说，都有责任处理一些行政的功能（例如，处理消息丢失的协议），和允许新的clients加入到活动的replication组。这个方法只应该在环境已经通过DB_ENV->rep_start被配置成一个 master或client后被调用。
DB_ENV->rep_elect：使replication组选举一个新的master，它在clients与master失去联系的时候和应用程序想在剩余的站点中选择一个新master的时候被调用。
DB_ENV ->set_rep_limit：在响应一个单独的调用DB_ENV->rep_process_message时，将要发送的数据量上强加一个上限。当一个客户执行恢复的时候，也就是说，当一个replica站点是同去同步master的时候，clients可能找master要大量的 log记录，那样它将使它们之间在未来一段时间内忙于循环发送大量数据，那么这时候可能就想在失去控制和接受其他正常消息前，用DB_ENV-> set_rep_limit限制master将发送的数据量。
为了把replication添加到应用程序，应用程序初始化必须改变，还有应用程序的通信底层构造必须编写。应用程序初始化改变相对简单，通信底层构造编码可能会很复杂。