Network Working Group E. Stokes
Request for Comments: 3384 IBM
Category: Informational R. Weiser
Digital Signature Trust
R. Moats
Lemur Networks
R. Huber
AT&T Laboratories
October 2002
Network Working Group E. Stokes
Request for Comments: 3384 IBM
Category: Informational R. Weiser
Digital Signature Trust
R. Moats
Lemur Networks
R. Huber
AT&T Laboratories
October 2002
Lightweight Directory Access Protocol (version 3) Replication Requirements
轻型目录访问协议（版本3）复制要求
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document discusses the fundamental requirements for replication of data accessible via the Lightweight Directory Access Protocol (version 3) (LDAPv3). It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories.
本文档讨论了通过轻量级目录访问协议（版本3）（LDAPv3）访问的数据复制的基本要求。它旨在成为提供信息目录之间互操作性所需的一般复制需求的聚集地。
Table of Contents
目录
1 Introduction...................................................2
2 Terminology....................................................3
3 The Models.....................................................5
4 Requirements...................................................7
4.1 General........................................................7
4.2 Model..........................................................8
4.3 Protocol.......................................................9
4.4 Schema........................................................10
4.5 Single Master.................................................10
4.6 Multi-Master..................................................11
4.7 Administration and Management.................................11
4.8 Security......................................................12
5 Security Considerations.......................................13
6 Acknowledgements..............................................13
1 Introduction...................................................2
2 Terminology....................................................3
3 The Models.....................................................5
4 Requirements...................................................7
4.1 General........................................................7
4.2 Model..........................................................8
4.3 Protocol.......................................................9
4.4 Schema........................................................10
4.5 Single Master.................................................10
4.6 Multi-Master..................................................11
4.7 Administration and Management.................................11
4.8 Security......................................................12
5 Security Considerations.......................................13
6 Acknowledgements..............................................13
7 References....................................................13
A Appendix A - Usage Scenarios..................................15
A.1 Extranet Example..............................................15
A.2 Consolidation Example.........................................15
A.3 Replication Heterogeneous Deployment Example..................16
A.4 Shared Name Space Example.....................................16
A.5 Supplier Initiated Replication................................16
A.6 Consumer Initiated Replication................................17
A.7 Prioritized attribute replication.............................17
A.8 Bandwidth issues..............................................17
A.9 Interoperable Administration and Management...................18
A.10 Enterprise Directory Replication Mesh.........................18
A.11 Failure of the Master in a Master-Slave Replicated Directory..19
A.12 Failure of a Directory Holding Critical Service Information...19
B Appendix B - Rationale........................................20
B.1 Meta-Data Implications........................................20
B.2 Order of Transfer for Replicating Data........................20
B.3 Schema Mismatches and Replication.............................21
B.4 Detecting and Repairing Inconsistencies Among Replicas........22
B.5 Some Test Cases for Conflict Resolution in Multi-Master
Replication...................................................23
B.6 Data Confidentiality and Data Integrity During Replication....27
B.7 Failover in Single-Master Systems.............................27
B.8 Including Operational Attributes in Atomic Operations.........29
Authors' Addresses............................................30
Full Copyright Statement......................................31
7 References....................................................13
A Appendix A - Usage Scenarios..................................15
A.1 Extranet Example..............................................15
A.2 Consolidation Example.........................................15
A.3 Replication Heterogeneous Deployment Example..................16
A.4 Shared Name Space Example.....................................16
A.5 Supplier Initiated Replication................................16
A.6 Consumer Initiated Replication................................17
A.7 Prioritized attribute replication.............................17
A.8 Bandwidth issues..............................................17
A.9 Interoperable Administration and Management...................18
A.10 Enterprise Directory Replication Mesh.........................18
A.11 Failure of the Master in a Master-Slave Replicated Directory..19
A.12 Failure of a Directory Holding Critical Service Information...19
B Appendix B - Rationale........................................20
B.1 Meta-Data Implications........................................20
B.2 Order of Transfer for Replicating Data........................20
B.3 Schema Mismatches and Replication.............................21
B.4 Detecting and Repairing Inconsistencies Among Replicas........22
B.5 Some Test Cases for Conflict Resolution in Multi-Master
Replication...................................................23
B.6 Data Confidentiality and Data Integrity During Replication....27
B.7 Failover in Single-Master Systems.............................27
B.8 Including Operational Attributes in Atomic Operations.........29
Authors' Addresses............................................30
Full Copyright Statement......................................31
1 Introduction
1导言
Distributing directory information throughout the network provides a two-fold benefit: (1) it increases the reliability of the directory through fault tolerance, and (2) it brings the directory content closer to the clients using the data. LDAP's success as an access protocol for directory information is driving the need to distribute LDAP directory content within the enterprise and Internet. Currently, LDAP does not define a replication mechanism, and mentions LDAP shadow servers (see [RFC2251]) in passing. A standard mechanism for directory replication in a multi-vendor environment is critical to the continued success of LDAP in the market place.
在整个网络中分发目录信息有两个好处：（1）它通过容错提高了目录的可靠性；（2）它使目录内容更接近使用数据的客户端。LDAP作为目录信息访问协议的成功推动了在企业和Internet中分发LDAP目录内容的需求。目前，LDAP没有定义复制机制，并顺便提到LDAP影子服务器（请参见[RFC2251]）。多供应商环境中目录复制的标准机制对于LDAP在市场上的持续成功至关重要。
This document sets out the requirements for replication between multiple LDAP servers. While RFC 2251 and RFC 2252 [RFC2252] set forth the standards for communication between LDAP clients and servers there are additional requirements for server-to-server communication. Some of these are covered here.
本文档规定了在多个LDAP服务器之间进行复制的要求。虽然RFC 2251和RFC 2252[RFC2252]规定了LDAP客户端和服务器之间的通信标准，但对服务器到服务器的通信还有其他要求。这里介绍了其中一些。
This document first introduces the terminology to be used, then presents the different replication models being considered.
本文档首先介绍要使用的术语，然后介绍所考虑的不同复制模型。
Requirements follow, along with security considerations. The reasoning that leads to the requirements is presented in the Appendices. This was done to provide a clean separation of the requirements from their justification.
接下来是需求，还有安全方面的考虑。导致需求的推理在附录中给出。这样做是为了将需求与其理由清晰地分开。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
2 Terminology
2术语
The following terms are used in this document:
本文件中使用了以下术语：
Anonymous Replication - Replication where the endpoints are identified to each other but not authenticated. Also known as "unauthenticated replication".
匿名复制—端点相互标识但未经过身份验证的复制。也称为“未经验证的复制”。
Area of replication - A whole or portion of a Directory Information Tree (DIT) that makes up a distinct unit of data to be replicated. An area of replication is defined by a replication base entry and includes all or some of the depending entries contained therein on a single server. It divides directory data into partitions whose propagation behavior may be independently configured from other partitions. Areas of replication may overlap or be nested. This is a subset of the definition of a "replicated area" in X.525 [X.525].
复制区域—目录信息树（DIT）的全部或部分，构成要复制的不同数据单元。复制区域由复制基础条目定义，包括单个服务器上其中包含的所有或部分从属条目。它将目录数据划分为多个分区，这些分区的传播行为可以独立于其他分区进行配置。复制区域可能重叠或嵌套。这是X.525[X.525]中“复制区域”定义的子集。
Atomic operation - A set of changes to directory data which the LDAP standards guarantee will be treated as a unit; all changes will be made or all the changes will fail.
原子操作-LDAP标准保证将作为一个单元处理的目录数据的一组更改；将进行所有更改，否则所有更改将失败。
Atomicity Information - Information about atomic operations passed as part of replication.
原子性信息—有关作为复制的一部分传递的原子操作的信息。
Conflict - A situation that arises when changes are made to the same directory data on different directory servers before replication can synchronize the data on the servers. When the servers do synchronize, they have inconsistent data - a conflict.
冲突—在复制可以同步服务器上的数据之前，对不同目录服务器上的相同目录数据进行更改时出现的一种情况。当服务器进行同步时，它们的数据不一致——这是一种冲突。
Conflict resolution - Deterministic procedures used to resolve change information conflicts that may arise during replication.
冲突解决—用于解决复制过程中可能出现的更改信息冲突的确定性过程。
Critical OID - Attributes or object classes defined in the replication agreement as being critical to the operation of the system. Changes affecting critical OIDs cause immediate initiation of a replica cycle. An example of a critical OID might be a password or certificate.
关键OID—复制协议中定义的对系统运行至关重要的属性或对象类。影响关键OID的更改会导致立即启动副本周期。关键OID的一个示例可能是密码或证书。
Fractional replication - The capability to filter a subset of attributes for replication.
部分复制—为复制筛选属性子集的功能。
Incremental Update - An update that contains only those attributes or entries that have changed.
增量更新-仅包含已更改的属性或条目的更新。
Master Replica - A replica that may be directly updated via LDAP operations. In a Master-Slave Replication system, the Master Replica is the only directly updateable replica in the replica-group.
主副本-可通过LDAP操作直接更新的副本。在主从复制系统中，主副本是副本组中唯一可直接更新的副本。
Master-Slave, or Single Master Replication - A replication model that assumes only one server, the master, allows LDAP write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication.
主从或单主复制—一种复制模型，假定只有一台服务器（主服务器）允许对复制数据进行LDAP写访问。请注意，主从复制可以被视为多主复制的适当子集。
Meta-Data - Data collected by the replication system that describes the status/state of replication.
元数据—复制系统收集的数据，用于描述复制的状态/状态。
Multi-Master Replication - A replication model where entries can be written and updated on any of several master replica copies without requiring communication with other master replicas before the write or update is performed.
多主副本复制—一种复制模型，其中可以在多个主副本副本中的任何一个副本上写入和更新条目，而无需在执行写入或更新之前与其他主副本通信。
One-way Replication - The process of synchronization in a single direction where the authoritative source information is provided to a replica.
单向复制—单向同步过程，其中向副本提供权威源信息。
Partial Replication - Partial Replication is Fractional Replication, Sparse Replication, or both.
部分复制-部分复制是部分复制、稀疏复制或两者兼有。
Propagation Behavior - The behavior of the synchronization process between a consumer and a supplier.
传播行为-消费者和供应商之间同步过程的行为。
Replica - An instance of an area of replication on a server.
副本—服务器上复制区域的实例。
Replica-Group - The servers that hold instances of a particular area of replication. A server may be part of several replica-groups.
副本组—保存特定复制区域实例的服务器。服务器可能是多个副本组的一部分。
Replica (or Replication) Cycle - The interval during which update information is exchanged between two or more replicas. It begins during an attempt to push data to, or pull data from, another replica or set of replicas, and ends when the data has successfully been exchanged or an error is encountered.
副本（或复制）周期—两个或多个副本之间交换更新信息的时间间隔。它开始于尝试将数据推送到或从另一个副本或一组副本中提取数据的过程，结束于成功交换数据或遇到错误的过程。
Replication - The process of synchronizing data distributed across directory servers and rectifying update conflicts.
复制—同步分布在目录服务器上的数据并纠正更新冲突的过程。
Replication Agreement - A collection of information describing the parameters of replication between two or more servers in a replica-group.
复制协议—描述复制组中两个或多个服务器之间复制参数的信息集合。
Replication Base Entry - The distinguished name of the root vertex of a replicated area.
Replication Base Entry—复制区域根顶点的可分辨名称。
Replication Initiation Conflict - A Replication Initiation Conflict is a situation where two sources want to update the same replica at the same time.
复制启动冲突—复制启动冲突是指两个源希望同时更新同一复制副本的情况。
Replication Session - A session set up between two servers in a replica-group to pass update information as part of a replica cycle.
复制会话—在副本组中的两台服务器之间设置的会话，用于作为副本周期的一部分传递更新信息。
Slave (or Read-Only) Replica - A replica that cannot be directly updated via LDAP requests. Changes may only be made via replication from a master replica. Read-only replicas may occur in both single-and multi-master systems.
从属（或只读）副本—无法通过LDAP请求直接更新的副本。只能通过从主复制副本进行复制来进行更改。只读副本可能出现在单主系统和多主系统中。
Sparse Replication - The capability to filter some subset of entries (other than a complete collection) of an area of replication.
稀疏复制—筛选复制区域的某些条目子集（而不是完整集合）的功能。
Topology - The shape of the directed graph describing the relationships between replicas.
拓扑-描述副本之间关系的有向图的形状。
Two-way Replication - The process of synchronization where change information flows bi-directionally between two replicas.
双向复制—同步过程，其中更改信息在两个副本之间双向流动。
Unauthenticated Replication - See Anonymous Replication.
未经验证的复制-请参阅匿名复制。
Update Propagation - Protocol-based process by which directory replicas are reconciled.
更新传播-基于协议的过程，通过该过程协调目录副本。
3 The Models
3.模型
The objective is to provide an interoperable, LDAPv3 directory synchronization protocol that is simple, efficient and flexible; supporting both multi-master and master-slave replication. The protocol must meet the needs of both the Internet and enterprise environments.
目标是提供一个简单、高效和灵活的可互操作的LDAPv3目录同步协议；支持多主机和主从复制。协议必须满足Internet和企业环境的需要。
There are five data consistency models.
有五种数据一致性模型。
Model 1: Transactional Consistency -- Environments that exhibit all four of the ACID properties (Atomicity, Consistency, Isolation, Durability) [ACID].
模型1：事务一致性——展示所有四种ACID属性（原子性、一致性、隔离性、持久性）的环境[ACID]。
Model 2: Eventual (or Transient) Consistency -- Environments where definite knowledge of the topology is provided through predetermined replication agreements. Examples include X.500 Directories (the X.500 model is single-master only) [X.501, X.525], Bayou [XEROX], and NDS (Novell Directory Services) [NDS]. In this model, every update propagates to every replica that it can reach via a path of stepwise eventual connectivity.
模型2：最终（或暂时）一致性——通过预定的复制协议提供拓扑结构的明确知识的环境。示例包括X.500目录（X.500型号仅为单主目录）[X.501、X.525]、Bayou[XEROX]和NDS（Novell目录服务）[NDS]。在这个模型中，每个更新都会通过逐步最终连接的路径传播到它可以到达的每个副本。
Model 3: Limited Effort Eventual (or Probabilistic) Consistency -- Environments that provide a statistical probability of convergence with knowledge of topology. An example is the Xerox Clearinghouse [XEROX2]. This model is similar to "Eventual Consistency", except where replicas may purge updates. Purging drops propagation changes when some replica time boundary is exceeded, thus leaving some changes replicated to only a portion of the topology. Transactional consistency is not preserved, though some weaker constraints on consistency are available.
模型3：有限努力最终（或概率）一致性——提供拓扑知识收敛统计概率的环境。例如，施乐信息交换所[XEROX2]。此模型类似于“最终一致性”，只是副本可能会清除更新。当超过某个副本时间边界时，清除会删除传播更改，从而使某些更改仅复制到拓扑的一部分。事务一致性不被保留，尽管在一致性方面存在一些较弱的约束。
Model 4: Loosest Consistency -- Environments where information is provided from an opportunistic or simple cache until stale. Complete knowledge of topology may not be shared among all replicas.
模型4：最松散的一致性——信息从一个机会主义的或简单的缓存中提供直到过时的环境。拓扑的完整知识可能无法在所有副本之间共享。
Model 5: Ad hoc -- A copy of a data store where no follow up checks are made for the accuracy/freshness of the data.
模型5：即席——数据存储的副本，其中不进行数据准确性/新鲜度的后续检查。
Consistency models 1, 2 and 3 involve the use of prearranged replication agreements among servers. While model 1 may simplify support for atomicity in multi-master systems, the added complexity of the distributed 2-phase commit required for Model 1 is significant; therefor, model 1 will not be considered at this time. Models 4 and 5 involve unregistered replicas that "pull" updates from another directory server without that server's knowledge. These models violate a directory's security policies.
一致性模型1、2和3涉及在服务器之间使用预先安排的复制协议。虽然模型1可以简化对多主系统中原子性的支持，但模型1所需的分布式2阶段提交的额外复杂性是显著的；因此，目前不考虑模型1。模型4和5涉及未注册的副本，这些副本在另一个目录服务器不知情的情况下从该服务器“拉”出更新。这些模型违反了目录的安全策略。
Models 2 and 3 illustrate two replication scenarios that must be handled: policy configuration through security management parameters (model 2), and hosting relatively static data and address information as in white-pages applications (model 3). Therefore, replication requirements are presented for models 2 and 3.
模型2和3演示了两种必须处理的复制场景：通过安全管理参数进行策略配置（模型2），以及在白页应用程序中托管相对静态的数据和地址信息（模型3）。因此，针对模型2和3提出了复制要求。
Interoperability among directories using LDAP replication may be limited for implementations that add semantics beyond those specified by the LDAP core documents (RFC 2251-2256, 2829, 2830). In addition, the "core" specifications include numerous features which are not mandatory-to-implement (e.g., RECOMMENDED or OPTIONAL). There are also numerous elective extensions. Thus LDAP replication interoperability between independent implementations of LDAP which support different options may be limited. Use of applicability
对于在LDAP核心文档（RFC 2251-22562892830）指定的语义之外添加语义的实现，使用LDAP复制的目录之间的互操作性可能会受到限制。此外，“核心”规范包括许多非强制实施的功能（例如，推荐或可选）。还有许多选修的扩展课程。因此，支持不同选项的独立LDAP实现之间的LDAP复制互操作性可能会受到限制。适用性的使用
statements to improve interoperability in particular application spaces is RECOMMENDED.
建议使用语句来改进特定应用程序空间中的互操作性。
4 Requirements
4要求
G1. LDAP Replication MUST support models 2 (Eventual Consistency) and 3 (Limited Effort Eventual Consistency) above.
G1。LDAP复制必须支持上述模型2（最终一致性）和模型3（有限努力最终一致性）。
G2. LDAP Replication SHOULD NOT preclude support for model 1 (Transactional Consistency) in the future.
G2。LDAP复制不应排除将来对模型1（事务一致性）的支持。
G3. LDAP replication SHOULD have minimal impact on system performance.
G3。LDAP复制对系统性能的影响应该最小。
G4. The LDAP Replication Standard SHOULD NOT limit the replication transaction rate.
G4。LDAP复制标准不应限制复制事务速率。
G5. The LDAP replication standard SHOULD NOT limit the size of an area of replication or a replica.
G5。LDAP复制标准不应限制复制区域或副本的大小。
G6. Meta-data collected by the LDAP replication mechanism MUST NOT grow without bound.
G6。LDAP复制机制收集的元数据不能在没有绑定的情况下增长。
G7. All policy and state data pertaining to replication MUST be accessible via LDAP.
七国集团。与复制相关的所有策略和状态数据都必须可以通过LDAP访问。
G8. LDAP replication MUST be capable of replicating the following:
八国集团。LDAP复制必须能够复制以下内容：
- all userApplication attribute types
- 所有用户应用程序属性类型
- all directoryOperation and distributedOperation attribute types defined in the LDAP "core" specifications (RFCs 2251- 2256, 2829-2830)
- LDAP“核心”规范（RFCs 2251-2256289-2830）中定义的所有directoryOperation和distributedOperation属性类型
- attribute subtypes
- 属性子类型
- attribute description options (e.g., ";binary" and Language Tags [RFC2596])
- 属性描述选项（例如，“二进制”和语言标记[RFC2596]）
G9. LDAP replication SHOULD support replication of directoryOperation and distributedOperation attribute types defined in standards track LDAP extensions.
G9。LDAP复制应支持复制在标准跟踪LDAP扩展中定义的directoryOperation和distributedOperation属性类型。
G10. LDAP replication MUST NOT support replication of dsaOperation attribute types as such attributes are DSA-specific.
G10。LDAP复制不得支持dsaOperation属性类型的复制，因为此类属性特定于DSA。
G11. The LDAP replication system should limit impact on the network by minimizing the number of messages and the amount of traffic sent.
G11。LDAP复制系统应该通过最小化消息数量和发送的通信量来限制对网络的影响。
M1. The model MUST support the following triggers for initiation of a replica cycle:
M1。模型必须支持以下触发器以启动副本周期：
a) A configurable set of scheduled times
a) 一组可配置的计划时间
b) Periodically, with a configurable period between replica cycles
b) 周期性地，在复制周期之间有一个可配置的周期
c) A configurable maximum amount of time between replica cycles
c) 副本周期之间可配置的最大时间量
d) A configurable number of accumulated changes
d) 累积更改的可配置数量
e) Change in the value of a critical OID
e) 临界OID值的变化
f) As the result of an automatic rescheduling after a replication initiation conflict
f) 由于复制启动冲突后自动重新安排的结果
g) A manual request for immediate replication
g) 立即复制的手动请求
With the exception of manual request, the specific trigger(s) and related parameters for a given server MUST be identified in a well-known place defined by the standard, e.g., the Replication Agreement(s).
除手动请求外，给定服务器的特定触发器和相关参数必须在标准定义的众所周知的地方进行标识，例如复制协议。
M2. The replication model MUST support both master-slave and multi-master relationships.
M2。复制模型必须同时支持主从和多主关系。
M3. An attribute in an entry MUST eventually converge to the same set of values in every replica holding that entry.
M3。条目中的属性最终必须收敛到包含该条目的每个副本中的同一组值。
M4. LDAP replication MUST encompass schema definitions, attribute names and values, access control information, knowledge information, and name space information.
M4。LDAP复制必须包含模式定义、属性名称和值、访问控制信息、知识信息和名称空间信息。
M5. LDAP replication MUST NOT require that all copies of the replicated information be complete, but MAY require that at least one copy be complete. The model MUST support Partial Replicas.
M5。LDAP复制不能要求已复制信息的所有副本都完整，但可能要求至少有一个副本完整。模型必须支持部分副本。
M6. The determination of which OIDs are critical MUST be configurable in the replication agreement.
M6。必须在复制协议中配置确定哪些OID是关键的。
M7. The parameters of the replication process among the members of the replica-group, including access parameters, necessary authentication credentials, assurances of confidentiality (encryption), and area(s) of replication MUST be defined in a standard location (e.g., the replication agreements).
M7。副本组成员之间的复制过程参数，包括访问参数、必要的身份验证凭据、机密性保证（加密）和复制区域，必须在标准位置（例如复制协议）中定义。
M8. The replication agreements SHOULD accommodate multiple servers receiving the same area of replication under a single predefined agreement.
M8。复制协议应适应在单个预定义协议下接收相同复制区域的多台服务器。
M9. LDAP replication MUST provide scalability to both enterprise and Internet environments, e.g., an LDAP server must be able to provide replication services to replicas within an enterprise as well as across the Internet.
M9。LDAP复制必须为企业和Internet环境提供可扩展性，例如，LDAP服务器必须能够为企业内以及跨Internet的副本提供复制服务。
M10. While different directory implementations can support different/extended schema, schema mismatches between two replicating servers MUST be handled. One way of handling such mismatches might be to raise an error condition.
M10。虽然不同的目录实现可以支持不同的/扩展模式，但必须处理两个复制服务器之间的模式不匹配。处理此类不匹配的一种方法可能是提出错误条件。
M11. There MUST be a facility that can update, or totally refresh, a replica-group from a standard data format, such as LDIF format [RFC2849].
M11。必须有一个工具可以从标准数据格式（如LDIF格式[RFC2849]）更新或完全刷新副本组。
M12. An update received by a consumer more than once MUST NOT produce a different outcome than if the update were received only once.
M12。消费者多次收到的更新不得产生与仅收到一次更新不同的结果。
P1. The replication protocol MUST provide for recovery and rescheduling of a replication session due to replication initiation conflicts (e.g., consumer busy replicating with other servers) and or loss of connection (e.g., supplier cannot reach a replica).
P1。由于复制启动冲突（例如，消费者忙于与其他服务器进行复制）和/或连接丢失（例如，供应商无法访问副本），复制协议必须提供复制会话的恢复和重新调度。
P2. LDUP replication SHOULD NOT send an update to a consumer if the consumer has previously acknowledged that update.
P2。如果使用者之前已确认更新，则LDUP复制不应向使用者发送更新。
P3. The LDAP replication protocol MUST allow for full update to facilitate replica initialization and reset loading utilizing a standardized format such as LDIF [RFC2849] format.
P3。LDAP复制协议必须允许完全更新，以便使用标准格式（如LDIF[RFC2849]格式）进行副本初始化和重置加载。
P4. Incremental replication MUST be allowed.
P4。必须允许增量复制。
P5. The replication protocol MUST allow either a master or slave replica to initiate the replication process.
P5。复制协议必须允许主副本或从副本启动复制过程。
P6. The protocol MUST preserve atomicity of LDAP operations as defined in RFC2251 [RFC2251]. In a multi-master environment this may lead to an unresolvable conflict. MM5 and MM6 discuss how to handle this situation.
P6。协议必须保留RFC2251[RFC2251]中定义的LDAP操作的原子性。在多主机环境中，这可能导致无法解决的冲突。MM5和MM6讨论如何处理这种情况。
P7. The protocol MUST support a mechanism to report schema mismatches between replicas discovered during a replication session.
P7。协议必须支持报告复制会话期间发现的副本之间的架构不匹配的机制。
SC1. A standard way to determine what replicas are held on a server MUST be defined.
SC1。必须定义确定在服务器上保存哪些复制副本的标准方法。
SC2. A standard schema for representing replication agreements MUST be defined.
SC2。必须定义用于表示复制协议的标准架构。
SC3. The semantics associated with modifying the attributes of replication agreements MUST be defined.
SC3。必须定义与修改复制协议属性相关的语义。
SC4. A standard method for determining the location of replication agreements MUST be defined.
SC4。必须定义确定复制协议位置的标准方法。
SC5. A standard schema for publishing state information about a given replica MUST be defined.
SC5。必须定义用于发布给定副本状态信息的标准架构。
SC6. A standard method for determining the location of replica state information MUST be defined.
SC6。必须定义用于确定副本状态信息位置的标准方法。
SC7. It MUST be possible for appropriately authorized administrators, regardless of their network location, to access replication agreements in the DIT.
SC7。无论网络位置如何，经过适当授权的管理员都必须能够访问DIT中的复制协议。
SC8. Replication agreements of all servers containing replicated information MUST be accessible via LDAP.
SC8。必须通过LDAP访问包含复制信息的所有服务器的复制协议。
SC9. An entry MUST be uniquely identifiable throughout its lifetime.
SC9。条目在其整个生命周期内必须是唯一可识别的。
SM1. A Single Master system SHOULD provide a fast method of promoting a slave replica to become the master replica.
SM1。单主系统应提供将从属副本升级为主副本的快速方法。
SM2. The master replica in a Single Master system SHOULD send all changes to read-only replicas in the order in which the master applied them.
SM2。单个主系统中的主副本应按照主副本应用更改的顺序将所有更改发送到只读副本。
MM1. The replication protocol SHOULD NOT saturate the network with redundant or unnecessary entry replication.
嗯。复制协议不应使用冗余或不必要的条目复制使网络饱和。
MM2. The initiator MUST be allowed to determine whether it will become a consumer or supplier during the synchronization startup process.
平方毫米。必须允许发起者确定在同步启动过程中它将成为消费者还是供应商。
MM3. During a replica cycle, it MUST be possible for the two servers to switch between the consumer and supplier roles.
嗯三。在复制周期中，两台服务器必须能够在消费者和供应商角色之间切换。
MM4. When multiple master replicas want to start a replica cycle with the same replica at the same time, the model MUST have an automatic and deterministic mechanism for resolving or avoiding replication initiation conflict.
嗯。当多个主副本希望同时使用同一副本启动副本周期时，模型必须具有自动和确定的机制来解决或避免复制启动冲突。
MM5. Multi-master replication MUST NOT lose information during replication. If conflict resolution would result in the loss of directory information, the replication process MUST store that information, notify the administrator of the nature of the conflict and the information that was lost, and provide a mechanism for possible override by the administrator.
嗯。多主机复制在复制过程中不得丢失信息。如果冲突解决会导致目录信息丢失，则复制过程必须存储该信息，将冲突的性质和丢失的信息通知管理员，并提供管理员可能进行覆盖的机制。
MM6. Multi-master replication MUST support convergence of the values of attributes and entries. Convergence may result in an event as described in MM5.
嗯。多主机复制必须支持属性和条目值的聚合。收敛可能导致MM5中所述的事件。
MM7. Multi-master conflict resolution MUST NOT depend on the in-order arrival of changes at a replica to assure eventual convergence.
嗯。多主冲突解决不能依赖于更改到达副本的顺序，以确保最终的收敛。
MM8. Multi-master replication MUST support read-only replicas as well as read-write replicas.
嗯八。多主机复制必须支持只读副本和读写副本。
AM1. Replication agreements MUST allow the initiation of a replica cycle to be administratively postponed to a more convenient period.
AM1。复制协议必须允许在管理上将副本周期的启动推迟到更方便的时间段。
AM2. Each copy of a replica MUST maintain audit history information of which servers it has replicated with and which servers have replicated with it.
AM2。副本的每个副本都必须维护其已与哪些服务器进行了复制以及已与哪些服务器进行了复制的审核历史记录信息。
AM3. Access to replication agreements, topologies, and policy attributes MUST be provided through LDAP.
AM3。必须通过LDAP提供对复制协议、拓扑和策略属性的访问。
AM4. The capability to check the differences between two replicas for the same information SHOULD be provided.
AM4。应提供检查两个副本之间相同信息差异的功能。
AM5. A mechanism to fix differences between replicas without triggering new replica cycles SHOULD be provided.
AM5。应提供一种在不触发新副本周期的情况下修复副本之间差异的机制。
AM6. The sequence of updates to access control information (ACI) and the data controlled by that ACI MUST be maintained by replication.
AM6。访问控制信息（ACI）的更新顺序以及由该ACI控制的数据必须通过复制来维护。
AM7. It MUST be possible to add a 'blank' replica to a replica-group, and force a full update from (one of) the Master(s), for the purpose of adding a new directory server to the system.
AM7。为了向系统添加新的目录服务器，必须能够向副本组添加“空白”副本，并强制（其中一个）主机进行完全更新。
AM8. Vendors SHOULD provide tools to audit schema compatibility within a potential replica-group.
AM8。供应商应提供工具来审核潜在副本组内的架构兼容性。
The terms "data confidentiality" and "data integrity" are defined in the Internet Security Glossary [RFC2828].
术语“数据机密性”和“数据完整性”在互联网安全术语表[RFC2828]中有定义。
S1. The protocol MUST support mutual authentication of the source and the replica directories during initialization of a replication session.
S1。在复制会话初始化期间，协议必须支持源目录和副本目录的相互身份验证。
S2. The protocol MUST support mutual verification of authorization of the source to send and the replica to receive replicated data during initialization of a replication session.
S2。协议必须支持在复制会话初始化期间对源发送和副本接收复制数据的授权进行相互验证。
S3. The protocol MUST also support the initialization of anonymous replication sessions.
S3。该协议还必须支持匿名复制会话的初始化。
S4. The replication protocol MUST support transfer of data with data integrity and data confidentiality.
S4。复制协议必须支持具有数据完整性和数据机密性的数据传输。
S5. The replication protocol MUST support the ability during initialization of a replication session for an authenticated source and replica to mutually decide to disable data integrity and data confidentiality within the context of and for the duration of that particular replication session.
S5。复制协议必须支持在经过身份验证的源和副本的复制会话初始化期间，在该特定复制会话的上下文中以及在该会话的持续时间内，相互决定禁用数据完整性和数据机密性的能力。
S6. To promote interoperability, there MUST be a mandatory-to-implement data confidentiality mechanism.
中六。为了促进互操作性，必须强制实施数据保密机制。
S7. The transport for administrative access MUST permit assurance of the integrity and confidentiality of all data transferred.
S7。管理访问的传输必须保证传输的所有数据的完整性和机密性。
S8. To support data integrity, there must be a mandatory-to-implement data integrity mechanism.
S8。为了支持数据完整性，必须有一个强制的机制来实现数据完整性。
5 Security Considerations
5安全考虑
This document includes security requirements (listed in section 4.8 above) for the replication model and protocol. As noted in Section 3, interoperability may be impacted when replicating among servers that implement non-standard extensions to basic LDAP semantics. Security-related and general LDAP interoperability will be significantly impacted by the degree of consistency with which implementations support existing and future standards detailing LDAP security models, such as a future standard LDAP access control model.
本文档包括复制模型和协议的安全要求（见上文第4.8节）。如第3节所述，在实现基本LDAP语义的非标准扩展的服务器之间进行复制时，互操作性可能会受到影响。安全相关的和通用的LDAP互操作性将受到实现支持现有和未来详细说明LDAP安全模型的标准（如未来标准LDAP访问控制模型）的一致性程度的显著影响。
6 Acknowledgements
6致谢
This document is based on input from IETF members interested in LDUP Replication.
本文档基于对LDUP复制感兴趣的IETF成员的输入。
7 References
7参考文献
[ACID] T. Haerder, A. Reuter, "Principles of Transaction-Oriented Database Recovery", Computing Surveys, Vol. 15, No. 4 (December 1983), pp. 287-317.
[ACID]T.Haerder，A.Reuter，“面向事务的数据库恢复原则”，计算调查，第15卷，第4期（1983年12月），第287-317页。
[NDS] Novell, "NDS Technical Overview", 104-000223-001, http://developer.novell.com/ndk/doc/ndslib/dsov_enu/data/ h6tvg4z7.html, September, 2000.
[NDS]Novell，“NDS技术概述”，104-000223-001，http://developer.novell.com/ndk/doc/ndslib/dsov_enu/data/ h6tvg4z7.html，2000年9月。
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol", RFC 2251, December 1997.
[RFC2251]Wahl，M.，Howes，T.和S.Kille，“轻量级目录访问协议”，RFC 2251，1997年12月。
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
[RFC2252]Wahl，M.，Coulbeck，A.，Howes，T.和S.Kille，“轻量级目录访问协议（v3）：属性语法定义”，RFC2252，1997年12月。
[RFC2253] Kille, S., Wahl, M. and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.
[RFC2253]Kille，S.，Wahl，M.和T.Howes，“轻量级目录访问协议（v3）：可分辨名称的UTF-8字符串表示”，RFC 2253，1997年12月。
[RFC2254] Howes, T., "The String Representation of LDAP Search Filters", RFC 2254, December 1997.
[RFC2254]Howes，T.，“LDAP搜索过滤器的字符串表示”，RFC2254，1997年12月。
[RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
[RFC2255]Howes，T.和M.Smith，“LDAP URL格式”，RFC2255，1997年12月。
[RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997.
[RFC2256]Wahl，M.，“用于LDAPv3的X.500（96）用户模式摘要”，RFC 2256，1997年12月。
[RFC2596] Wahl, M. and T. Howes, "Use of Language Codes in LDAP", RFC 2596, May 1999.
[RFC2596]Wahl，M.和T.Howes，“LDAP中语言代码的使用”，RFC2596，1999年5月。
[RFC2828] Shirey, R. "Internet Security Glossary", FYI 36, RFC 2828, May 2000.
[RFC2828]Shirey，R.《互联网安全词汇》，第36期，RFC 28282000年5月。
[RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, "Authentication Methods for LDAP", RFC 2829, May 2000.
[RFC2829]Wahl，M.，Alvestrand，H.，Hodges，J.和R.Morgan，“LDAP的身份验证方法”，RFC 28292000年5月。
[RFC2830] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000.
[RFC2830]Hodges，J.，Morgan，R.和M.Wahl，“轻量级目录访问协议（v3）：传输层安全扩展”，RFC 28302000年5月。
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF)", RFC 2849, June 2000.
[RFC2849]Good，G.，“LDAP数据交换格式（LDIF）”，RFC 28492000年6月。
[X.501] ITU-T Recommendation X.501 (1993), | ISO/IEC 9594-2: 1993, Information Technology - Open Systems Interconnection - The Directory: Models.
[X.501]ITU-T建议X.501（1993），| ISO/IEC 9594-2:1993，信息技术-开放系统互连-目录：模型。
[X.525] ITU-T Recommendation X.525 (1997), | ISO/IEC 9594-9: 1997, Information Technology - Open Systems Interconnection - The Directory: Replication.
[X.525]ITU-T建议X.525（1997），| ISO/IEC 9594-9:1997，信息技术-开放系统互连-目录：复制。
[XEROX] C. Hauser, "Managing update conflicts in Bayou, a weakly connected replicated storage system". Palo Alto, CA: Xerox PARC, Computer Science Laboratory; 1995 August; CSL-95-4.
[XEROX]C.Hauser，“管理Bayou（一个弱连接的复制存储系统）中的更新冲突”。加州帕洛阿尔托：施乐PARC，计算机科学实验室；1995年8月；CSL-95-4。
[XEROX2] Alan D. Demers, Mark Gealy, Daniel Greene, Carl Hauser, Wesley Irish, John Larson, Sue Manning, Scott Shenker, Howard Sturgis, Daniel Swinehart, Douglas Terry, Don Woods, "Epidemic Algorithms for Replicated Database Maintenance". Palo Alto, CA, Xerox PARC, January 1989.
[XEROX2]Alan D.Demers、Mark Gealy、Daniel Greene、Carl Hauser、Wesley Irish、John Larson、Sue Manning、Scott Shenker、Howard Sturgis、Daniel Swinehart、Douglas Terry、Don Woods，“复制数据库维护的流行病算法”。加利福尼亚州帕洛阿尔托，施乐帕洛阿尔托研究中心，1989年1月。
A. APPENDIX A - Usage Scenarios
A.附录A-使用场景
The following directory deployment examples are intended to validate our replication requirements. A heterogeneous set of directory implementations is assumed for all the cases below. This material is intended as background; no requirements are presented in this Appendix.
以下目录部署示例旨在验证我们的复制需求。对于以下所有情况，都假定有一组异构的目录实现。本材料旨在作为背景材料；本附录中未提出任何要求。
A company has a trading partner with whom it wishes to share directory information. This information may be as simple as a corporate telephone directory, or as complex as an extranet workflow application. For performance reasons, the company wishes to place a replica of its directory within the Partner Company, rather than exposing its directory beyond its firewall.
公司有一个希望与之共享目录信息的贸易伙伴。此信息可能与公司电话簿一样简单，也可能与外部网工作流应用程序一样复杂。出于性能原因，公司希望在合作伙伴公司内放置其目录的副本，而不是将其目录暴露在防火墙之外。
The requirements that follow from this scenario are:
此场景的要求如下：
- One-way replication, single mastered.
- 单向复制，单控制。
- Authentication of clients.
- 客户端的身份验证。
- Common access control and access control identification.
- 通用访问控制和访问控制标识。
- Secure transmission of updates.
- 安全传输更新。
- Selective attribute replication (Fractional Replication), so that only partial entries can be replicated.
- 选择性属性复制（部分复制），因此只能复制部分条目。
Company A acquires company B. Each company has an existing directory.
A公司收购B公司。每个公司都有一个现有的目录。
During the transition period, as the organizations are merged, both directory services must coexist. Company A may wish to attach company B's directory to its own.
在过渡期间，随着组织的合并，两个目录服务必须共存。A公司可能希望将B公司的目录附加到其自己的目录中。
The requirements that follow from this scenario are:
此场景的要求如下：
- Multi-Master replication.
- 多主机复制。
- Common access control model. Access control model identification.
- 公共访问控制模型。访问控制模型识别。
- Secure transmission of updates.
- 安全传输更新。
- Replication between DITs with potentially differing schema.
- 具有潜在不同架构的DIT之间的复制。
An organization may choose to deploy directory implementations from multiple vendors, to enjoy the distinguishing benefits of each.
一个组织可以选择部署来自多个供应商的目录实现，以享受每个供应商的独特优势。
In this case, multi-master replication is required to ensure that the multiple replicas of the DIT are synchronized. Some vendors may provide directory clients, which are tied to their own directory service.
在这种情况下，需要多主机复制以确保DIT的多个副本同步。一些供应商可能提供目录客户端，这些客户端与他们自己的目录服务相关联。
The requirements that follow from this scenario are:
此场景的要求如下：
- Multi-Master replication
- 多主机复制
- Common access control model and access control model identification.
- 公共访问控制模型和访问控制模型标识。
- Secure transmission of updates.
- 安全传输更新。
- Replication among DITs with potentially differing schemas.
- 具有潜在不同模式的DIT之间的复制。
Two organizations may choose to cooperate on some venture and need a shared name space to manage their operation. Both organizations will require administrative rights over the shared name space.
两个组织可能会选择在某些风险项目上进行合作，并需要共享名称空间来管理其运营。这两个组织都需要共享名称空间的管理权限。
The requirements that follow from this scenario are:
此场景的要求如下：
- Multi-Master replication.
- 多主机复制。
- Common access control model and access control model identification.
- 公共访问控制模型和访问控制模型标识。
- Secure transmission of updates.
- 安全传输更新。
This is a single master environment that maintains a number of replicas of the DIT by pushing changes based on a defined schedule.
这是一个单一的主环境，通过根据定义的计划推送更改来维护DIT的多个副本。
The requirements that follow from this scenario are:
此场景的要求如下：
- Single-master environment.
- 单主环境。
- Supplier-initiated replication.
- 供应商发起的复制。
- Secure transmission of updates.
- 安全传输更新。
Again a single mastered replication topology, but the slave replica initiates the replication exchange rather than the master. An example of this is a replica that resides on a laptop computer that may run disconnected for a period of time.
同样是单个主复制拓扑，但从复制副本启动复制交换，而不是主复制拓扑。这方面的一个示例是驻留在笔记本电脑上的副本，该笔记本电脑可能会断开连接运行一段时间。
The requirements that follow from this scenario are:
此场景的要求如下：
- Single-master environment.
- 单主环境。
- Consumer initiated replication.
- 使用者启动的复制。
- Open scheduling (anytime).
- 开放式日程安排（随时）。
The password attribute can provide an example of the requirement for prioritized attribute replication. A user is working in Utah and the administrator resides in California. The user has forgotten his password. So the user calls or emails the administrator to request a new password. The administrator provides the updated password (a change).
密码属性可以提供优先级属性复制要求的示例。用户在犹他州工作，管理员居住在加利福尼亚州。用户忘记了密码。因此，用户致电或通过电子邮件向管理员请求新密码。管理员提供更新的密码（更改）。
Under normal conditions, the directory replicates to a number of different locations overnight. But corporate security policy states that passwords are critical and the new value must be available immediately (e.g., shortly) after any change. Replication needs to occur immediately for critical attributes/entries.
在正常情况下，目录会在一夜之间复制到多个不同的位置。但公司安全政策规定密码至关重要，任何更改后新值必须立即可用（例如，很快可用）。对于关键属性/条目，需要立即进行复制。
The requirements that follow from this scenario are:
此场景的要求如下：
- Incremental replication of changes.
- 增量复制更改。
- Immediate replication on change of certain attributes.
- 更改某些属性时立即复制。
- Replicate based on time/attribute semantics.
- 基于时间/属性语义进行复制。
The replication of Server (A) R/W replica (a) in Kathmandu is handled via a dial up phone link to Paris where server (B) R/W replica of (a) resides. Server (C) R/W replica of (a) is connected by a T1 connection to server (B). Each connection has a different performance characteristic.
加德满都的服务器（A）R/W副本（A）的复制通过拨号电话连接到巴黎（A）的服务器（B）R/W副本所在地进行。服务器（C）的R/W副本（a）通过T1连接连接到服务器（B）。每个连接都有不同的性能特征。
The requirements that follow from this scenario are:
此场景的要求如下：
- Minimize repetitive updates when replicating from multiple replication paths.
- 从多个复制路径进行复制时，尽量减少重复更新。
- Incremental replication of changes.
- 增量复制更改。
- Provide replication cycles to delay and/or retry when connections cannot be reached.
- 提供复制周期，以便在无法连接时延迟和/或重试。
- Allowances for consumer initiated or supplier initiated replication.
- 用户启动或供应商启动复制的容差。
The administrator with administrative authority of the corporate directory which is replicated by numerous geographically dispersed LDAP servers from different vendors notices that the replication process is not completing correctly as the change log is continuing to grow and/or error messages inform him. The administrator uses his $19.95 RepCo LDAP directory replication diagnostic tools to look at Root DSE replica knowledge on server 17 and determines that server 42 made by LDAP'RUS Inc. is not replicating properly due to an object conflict. Using his Repco Remote repair tools he connects to server 42 and resolves the conflict on the remote server.
具有公司目录管理权限的管理员（该目录由来自不同供应商的多个地理位置分散的LDAP服务器复制）注意到，由于更改日志不断增加和/或错误消息通知，复制过程没有正确完成。管理员使用其$19.95 RepCo LDAP目录复制诊断工具查看服务器17上的根DSE副本知识，并确定LDAP'RUS Inc.制造的服务器42由于对象冲突而无法正确复制。他使用Repco远程修复工具连接到服务器42并解决远程服务器上的冲突。
The requirements that follow from this scenario are:
此场景的要求如下：
- Provide replication audit history.
- 提供复制审核历史记录。
- Provide mechanisms for managing conflict resolution.
- 提供管理冲突解决的机制。
- Provide LDAP access to predetermined agreements, topology and policy attributes.
- 提供对预定协议、拓扑和策略属性的LDAP访问。
- Provide operations for comparing replica's content for validity.
- 提供用于比较副本内容有效性的操作。
- Provide LDAP access to status and audit information.
- 提供对状态和审核信息的LDAP访问。
A Corporation builds a mesh of directory servers within the enterprise utilizing LDAP servers from various vendors. Five servers are holding the same area of replication. The predetermined replication agreement(s) for the enterprise mesh are under a single management, and the security domain allows a single predetermined replication agreement to manage the 5 servers' replication.
一家公司利用来自不同供应商的LDAP服务器在企业内构建目录服务器网格。五台服务器拥有相同的复制区域。企业mesh的预定复制协议在单一管理下，安全域允许单个预定复制协议管理5台服务器的复制。
The requirements that follow from this scenario are:
此场景的要求如下：
- One predefined replication agreement that manages a single area of replication that is held on numerous servers.
- 一个预定义的复制协议，用于管理多台服务器上的单个复制区域。
- Common support of replication management knowledge across vendor implementation.
- 跨供应商实施对复制管理知识的共同支持。
- Rescheduling and continuation of a replication cycle when one server in a replica-group is busy and/or unavailable.
- 当副本组中的一台服务器繁忙和/或不可用时，重新安排和继续复制周期。
A company has a corporate directory that is used by the corporate email system. The directory is held on a mesh of servers from several vendors. A corporate relocation results in the closing of the location where the master copy of the directory is located. Employee information (such as mailbox locations and employee certificate information) must be kept up to date or mail cannot be delivered.
公司拥有公司电子邮件系统使用的公司目录。该目录保存在多个供应商的服务器网格上。公司重新定位会导致目录主副本所在位置的关闭。员工信息（如邮箱位置和员工证书信息）必须保持最新，否则邮件无法送达。
The requirements that follow from this scenario are:
此场景的要求如下：
- An existing slave replica must be "promote-able" to become the new master.
- 现有从属副本必须“可升级”才能成为新的主副本。
- The "promotion" must be done without significant downtime, since updates to the directory will continue.
- “升级”必须在没有明显停机的情况下完成，因为目录更新将继续进行。
An ISP uses a policy management system that uses a directory as the policy data repository. The directory is replicated in several different sites on different vendors' products to avoid single points of failure. It is imperative that the directory be available and be updateable even if one site is disconnected from the network. Changes to the data must be traceable, and it must be possible to determine how changes made from different sites interacted.
ISP使用策略管理系统，该系统使用目录作为策略数据存储库。该目录在不同供应商产品的多个不同站点中复制，以避免单点故障。即使一个站点与网络断开连接，目录也必须可用且可更新。对数据的更改必须是可跟踪的，并且必须能够确定不同站点的更改是如何相互作用的。
The requirements that follow from this scenario are:
此场景的要求如下：
- Multi-master replication.
- 多主机复制。
- Ability to reschedule replication sessions.
- 能够重新安排复制会话。
- Support for manual review and override of replication conflict resolution.
- 支持手动检查和覆盖复制冲突解决。
B. APPENDIX B - Rationale
B.附录B-理由
This Appendix gives some of the background behind the requirements. It is included to help the protocol designers understand the thinking behind some of the requirements and to present some of the issues that should be considered during design. With the exception of section B.8, which contains a suggested requirement for the update to RFC 2251, this Appendix does not state any formal requirements.
本附录给出了要求背后的一些背景。它的目的是帮助协议设计人员理解某些需求背后的思想，并提出设计过程中应考虑的一些问题。除包含RFC 2251更新建议要求的第B.8节外，本附录未说明任何正式要求。
Requirement G4 states that meta-data must not grow without bound. This implies that meta-data must, at some point, be purged from the system. This, in turn, raises concerns about stability. Purging meta-data before all replicas have been updated may lead to incomplete replication of change information and inconsistencies among replicas. Therefore, care must be taken setting up the rules for purging meta-data from the system while still ensuring that meta-data will not grow forever.
G4要求声明元数据不能无限制地增长。这意味着元数据必须在某个时候从系统中清除。这反过来又引起了人们对稳定的担忧。在更新所有副本之前清除元数据可能会导致更改信息的复制不完整以及副本之间的不一致。因此，必须注意设置从系统中清除元数据的规则，同时确保元数据不会永远增长。
Situations may arise where it would be beneficial to replicate data out-of-order (e.g., send data to consumer replicas in a different order than it was processed at the supplier replica). One such case might occur if a large bulk load was done on the master server in a single-master environment and then a single change to a critical OID (a password change, for example) was then made. Rather than wait for all the bulk data to be sent to the replicas, the password change might be moved to the head of the queue and be sent before all the bulk data was transferred. Other cases where this might be considered are schema changes or changes to critical policy data stored in the directory.
可能会出现这样的情况：无序复制数据是有益的（例如，将数据发送到消费者副本的顺序与在供应商副本上处理的顺序不同）。如果在一个主服务器环境中对主服务器进行了大量加载，然后对关键OID进行了一次更改（例如，密码更改），则可能会出现这种情况。与等待所有批量数据发送到副本不同，密码更改可能会移动到队列的头部，并在传输所有批量数据之前发送。可以考虑的其他情况是模式更改或对目录中存储的关键策略数据的更改。
While there are practical benefits to allowing out-of-order transfer, there are some negative consequences as well. Once out-of-order transfers are permitted, all receiving replicas must be prepared to deal with data and schema conflicts that might arise.
虽然允许无序转移有实际好处，但也有一些负面后果。一旦允许无序传输，所有接收副本都必须准备好处理可能出现的数据和模式冲突。
As an example, assume that schema changes are critical and must be moved to the front of the replication queue. Now assume that a schema change deletes an attribute for some object class. It is possible that some of the operations ahead of the schema change in the queue are operations to delete values of the soon-to-be-deleted
例如，假设架构更改非常关键，必须移动到复制队列的前面。现在假设模式更改删除了某个对象类的属性。队列中架构更改之前的一些操作可能是删除即将删除的值的操作
attribute so that the schema change can be done with no problems. If the schema change moves to the head of the queue, the consumer servers might have to delete an attribute that still has values, and then receive requests to delete the values of an attribute that is no longer defined.
属性，以便模式更改可以顺利完成。如果模式更改移动到队列的头部，则使用者服务器可能必须删除仍然具有值的属性，然后接收删除不再定义的属性值的请求。
In the multi-master case, similar situations can arise when simultaneous changes are made to different replicas. Thus, multi-master systems must have conflict resolution algorithms in place to handle such situations. But in the single-master case conflict resolution is not needed unless the master is allowed to send data out-of-order. This is the reasoning behind requirement SM2, which recommends that data always be sent in order in single-master replication.
在多主机情况下，对不同副本同时进行更改时，可能会出现类似的情况。因此，多主系统必须有适当的冲突解决算法来处理此类情况。但在单主机情况下，不需要冲突解决，除非允许主机无序发送数据。这就是需求SM2背后的原因，它建议在单主机复制中始终按顺序发送数据。
Note that even with this restriction, the concept of a critical OID is still useful in single-master replication. An example of its utility can be found in section A.7.
请注意，即使有此限制，关键OID的概念在单主机复制中仍然很有用。其实用性示例见第A.7节。
Multi-vendor environments are the primary area of interest for LDAP replication standards. Some attention must thus be paid to the issue of schema mismatches, since they can easily arise when vendors deliver slightly different base schema with their directory products. Even when both products meet the requirements of the standards [RFC2252], the vendors may have included additional attributes or object classes with their products. When two different vendors' products attempt to replicate, these additions can cause schema mismatches. Another potential cause of schema mismatches is discussed in section A.3.
多供应商环境是LDAP复制标准的主要关注领域。因此，必须注意模式不匹配的问题，因为当供应商提供与目录产品稍有不同的基本模式时，很容易出现这种问题。即使这两种产品都满足标准[RFC2252]的要求，供应商也可能在其产品中包含其他属性或对象类。当两个不同供应商的产品尝试复制时，这些添加可能会导致模式不匹配。模式不匹配的另一个潜在原因在A.3节中讨论。
There are only a few possible responses when a mismatch is discovered.
当发现不匹配时，只有少数可能的响应。
- Raise an error condition and ignore the data. This should always be allowed and is the basis for requirement P8 and the comment on M10.
- 引发错误条件并忽略数据。这应该始终是允许的，并且是要求P8和M10注释的基础。
- Map/convert the data to the form required by the consuming replica. A system may choose this course; requirement M10 is intended to allow this option. The extent of the conversion is up to the implementation; in the extreme it could support use of the replication protocol in meta-directories.
- 将数据映射/转换为使用复制副本所需的格式。一个系统可以选择这门课程；要求M10旨在允许此选项。转化的程度取决于实施情况；在极端情况下，它可以支持在元目录中使用复制协议。
- Quietly ignore (do not store on the consumer replica and do not raise an error condition) any data that does not conform to the schema at the consumer.
- 安静地忽略（不要存储在使用者副本上，也不要引发错误条件）任何不符合使用者模式的数据。
Requirement M10 is intended to exclude the last option.
要求M10旨在排除最后一个选项。
Requirement AM8 suggests that vendors should provide tools to help discover schema mismatches when replication is being set up. But schema will change after the initial setup, so the replication system must be prepared to handle unexpected mismatches.
需求AM8建议供应商提供工具，以帮助在设置复制时发现模式不匹配。但模式在初始设置后会发生更改，因此复制系统必须准备好处理意外的不匹配。
Normal IETF practice in protocol implementation suggests that one be strict in what one sends and be flexible in what one receives. The parallel in this case is that a supplier should be prepared to receive an error notification for any schema mismatch, but a consumer may choose to do a conversion instead.
IETF在协议实现中的正常实践表明，发送内容必须严格，接收内容必须灵活。与此类似的是，供应商应该准备好接收任何模式不匹配的错误通知，但消费者可以选择进行转换。
The other option that can be considered in this situation is the use of fractional replication. If replication is set up so only the common attributes are replicated, mismatches can be avoided.
在这种情况下可以考虑的另一种选择是使用部分复制。如果复制设置为仅复制公共属性，则可以避免不匹配。
One additional consideration here is replication of the schema itself. M4 requires that it be possible to replicate schema. If a consumer replica is doing conversion, extreme care should be taken if schema elements are replicated since some attributes are intended to have different definitions on different replicas.
这里需要考虑的另一个问题是模式本身的复制。M4要求可以复制模式。如果使用者副本正在进行转换，则在复制架构元素时应格外小心，因为某些属性在不同副本上具有不同的定义。
For fractional replication, the protocol designers and implementors should give careful consideration to the way they handle schema replication. Some options for schema replication include:
对于部分复制，协议设计者和实现者应该仔细考虑他们处理模式复制的方式。架构复制的一些选项包括：
- All schema elements are replicated.
- 所有模式元素都被复制。
- Schema elements are replicated only if they are used by attributes that are being replicated.
- 架构元素只有在被复制的属性使用时才会被复制。
- Schema are manually configured on the servers involved in fractional replication; schema elements are not replicated via the protocol.
- 在参与部分复制的服务器上手动配置模式；架构元素不会通过协议进行复制。
Despite the best efforts of designers, implementors, and operators, inconsistencies will occasionally crop up among replicas in production directories. Tools will be needed to detect and to correct these inconsistencies.
尽管设计人员、实现人员和操作员尽了最大努力，但生产目录中的副本偶尔会出现不一致。需要工具来检测和纠正这些不一致。
A special client may accomplish detection through periodic comparisons of replicas. This client would typically read two replicas of the same replication base entry and compare the answers, possibly by BINDing to each of the two replicas to be compared and reading them both. In cases where the directory automatically reroutes some requests (e.g., chaining), mechanisms to force access to a particular replica should be supplied.
特殊客户端可以通过定期比较副本来完成检测。此客户端通常会读取同一复制基条目的两个副本并比较答案，可能是通过绑定到要比较的两个副本中的每一个并同时读取它们。在目录自动重新路由某些请求（例如链接）的情况下，应提供强制访问特定副本的机制。
Alternatively, the server could support a special request to handle this situation. A client would invoke an operation at some server. It would cause that server to extract the contents from some other server it has a replication agreement with and report the differences back to the client as the result.
或者，服务器可以支持处理这种情况的特殊请求。客户端将调用某个服务器上的操作。这将导致该服务器从与之有复制协议的其他服务器提取内容，并将差异报告回客户端。
If an inconsistency is found, it needs to be repaired. To determine the appropriate repair, the administrator will need access to the replication history to figure out how the inconsistency occurred and what the correct repair should be.
如果发现不一致，则需要修复。要确定适当的修复，管理员需要访问复制历史记录，以了解不一致性是如何发生的，以及正确的修复应该是什么。
When a repair is made, it should be restricted to the replica that needs to be fixed; the repair should not cause new replication events to be started. This may require special tools to change the local data store without triggering replication.
进行修复时，应仅限于需要修复的复制副本；修复不应导致启动新的复制事件。这可能需要特殊工具来更改本地数据存储，而不触发复制。
Requirements AM2, AM4, and AM5 address these needs.
要求AM2、AM4和AM5解决了这些需求。
Use of multi-master replication inevitably leads to the possibility that incompatible changes will be made simultaneously on different servers. In such cases, conflict resolution algorithms must be applied.
使用多主机复制不可避免地会导致在不同的服务器上同时进行不兼容的更改。在这种情况下，必须应用冲突解决算法。
As a guiding principle, conflict resolution should avoid surprising the user. One way to do this is to adopt the principle that, to the extent possible, conflict resolution should mimic the situation that would happen if there were a single server where all the requests were handled.
作为指导原则，冲突解决应避免让用户感到惊讶。实现这一点的一种方法是采用这样的原则，即冲突解决应尽可能模拟如果只有一台服务器处理所有请求时可能发生的情况。
While this is a useful guideline, there are some situations where it is impossible to implement. Some of these cases are examined in this section. In particular, there are some cases where data will be "lost" in multi-master replication that would not be lost in a single-server configuration.
虽然这是一个有用的指导方针，但在某些情况下是不可能实施的。本节将研究其中一些案例。特别是，在某些情况下，数据将在多主机复制中“丢失”，而在单个服务器配置中不会丢失。
In the examples below, assume that there are three replicas, A, B, and C. All three replicas are updateable. Changes are made to replicas A and B before replication allows either replica to see the change made on the other. In discussion of the multi-master cases, we assume that the change to A takes precedence using whatever rules are in force for conflict resolution.
在下面的示例中，假设有三个副本A、B和C。所有三个副本都是可更新的。在复制之前对复制副本A和B进行更改，使其中一个复制副本可以看到另一个复制副本上所做的更改。在讨论多主机情况时，我们假设使用冲突解决的任何有效规则，对A的更改优先。
A user creates a new entry with distinguished name DN on A. At the same time, a different user adds an entry with the same distinguished name on B.
用户在A上创建具有可分辨名称DN的新条目。同时，其他用户在B上添加具有相同可分辨名称的条目。
In the single-server case, one of the create operations would have occurred before the other, and the second request would have failed.
在单服务器情况下，其中一个创建操作将在另一个之前发生，第二个请求将失败。
In the multi-master case, each create was successful on its originating server. The problem is not detected until replication takes place. When a replication request to create a DN that already exists arrives at one of the servers, conflict resolution is invoked. (Note that the two requests can be distinguished even though they have the same DN because every entry has some sort of unique identifier per requirement SC9.)
在多主机情况下，每个创建都在其原始服务器上成功。在复制发生之前，不会检测到该问题。当创建已经存在的DN的复制请求到达其中一台服务器时，将调用冲突解决。（请注意，即使这两个请求具有相同的DN，也可以对其进行区分，因为根据需求SC9，每个条目都有某种唯一标识符。）
As noted above, in these discussions we assume that the change from replica A has priority based on the conflict resolution algorithm. Whichever change arrives first, requirement MM6 says that the values from replica A must be those in place on all replicas at the end of the replication cycle. Requirement MM5 states that the system cannot quietly ignore the values from replica B.
如上所述，在这些讨论中，我们假设来自副本A的更改具有基于冲突解决算法的优先级。无论哪个更改最先到达，需求MM6都指出，复制副本A中的值必须是复制周期结束时所有复制副本上的值。需求MM5指出，系统不能安静地忽略副本B中的值。
The values from replica B might be logged with some notice to the administrators, or they might be added to the DIT with a machine generated DN (again with notice to the administrators). If they are stored with a machine generated DN, the same DN must be used on all servers in the replica-group (otherwise requirement M3 would be violated). Note that in the case where the entry in question is a container, storage with a machine generated DN provides a place where descendent entries may be stored if any descendents were generated before the replication cycle was completed.
副本B中的值可能会记录下来并通知管理员，也可能会使用计算机生成的DN将它们添加到DIT中（再次通知管理员）。如果它们与机器生成的DN一起存储，则必须在副本组中的所有服务器上使用相同的DN（否则将违反M3要求）。请注意，在所讨论的条目是容器的情况下，如果在复制周期完成之前生成了任何子条目，则机器生成DN的存储提供了一个存储子条目的位置。
In any case, some mechanism must be provided to allow the administrator to reverse the conflict resolution algorithm and force the values originally created on B into place on all replicas if desired.
在任何情况下，必须提供某种机制，以允许管理员反转冲突解决算法，并在需要时强制在B上最初创建的值在所有副本上就位。
On replica A, an entry with distinguished name DN1 is renamed to DN. At the same time on replica B, an entry with distinguished name DN2 is renamed to DN.
在副本A上，可分辨名称为DN1的条目重命名为DN。同时，在副本B上，可分辨名称为DN2的条目重命名为DN。
In the single-server case, one rename operation would occur before the other and the second would fail since the target name already exists.
在单服务器情况下，一个重命名操作将在另一个之前发生，第二个重命名操作将失败，因为目标名称已经存在。
In the multi-master case, each rename was successful on its originating server. Assuming that the change on A has priority in the conflict resolution sense, DN will be left with the values from DN1 in all replicas and DN1 will no longer exist in any replica. The question is what happens to DN2 and its original values.
在多主机情况下，每次重命名都在其原始服务器上成功。假设在冲突解决意义上，对的更改具有优先级，则DN将保留所有副本中来自DN1的值，并且任何副本中都不再存在DN1。问题是DN2及其原始值会发生什么变化。
Requirement MM5 states that these values must be stored somewhere. They might be logged, they might be left in the DIT as the values of DN2, or they might be left in the DIT as the values of some machine generated DN. Leaving them as the values of DN2 is attractive since it is the same as the single-server case, but if a new DN2 has already been created before the replica cycle finishes, there are some very complex cases to resolve. Any of the solutions described in this paragraph would be consistent with requirement MM5.
需求MM5规定这些值必须存储在某个地方。它们可能会被记录，它们可能会作为DN2的值留在DIT中，或者它们可能会作为某些机器生成的DN的值留在DIT中。将其保留为DN2的值很有吸引力，因为它与单服务器情况相同，但如果在副本周期结束之前已经创建了新的DN2，则需要解决一些非常复杂的情况。本段中描述的任何解决方案都应符合MM5要求。
There is an entry with distinguished name DN that contains attributes X, Y, and Z. The value of X is 1. On replica A, a ModifyRequest is processed which includes modifications to change that value of X from 1 to 0 and to set the value of Y to "USER1". At the same time, replica B processes a ModifyRequest which includes modifications to change the value of X from 1 to 0 and to set the value of Y to "USER2" and the value of Z to 42. The application in this case is using X as a lock and is depending on the atomic nature of ModifyRequests to provide mutual exclusion for lock access.
有一个具有可分辨名称DN的条目，该条目包含属性X、Y和Z。X的值为1。在副本A上，处理ModifyRequest，其中包括将X值从1更改为0以及将Y值设置为“USER1”的修改。同时，副本B处理ModifyRequest，其中包括将X的值从1更改为0，并将Y的值设置为“USER2”，将Z的值设置为42的修改。本例中的应用程序使用X作为锁，并根据ModifyRequests的原子性质为锁访问提供互斥。
In the single-server case, the two operations would have occurred sequentially. Since a ModifyRequest is atomic, the entire first operation would succeed. The second ModifyRequest would fail, since the value of X would be 0 when it was attempted, and the modification changing X from 1 to 0 would thus fail. The atomicity rule would cause all other modifications in the ModifyRequest to fail as well.
在单服务器情况下，这两个操作将按顺序进行。因为ModifyRequest是原子的，所以整个第一个操作都会成功。第二个ModifyRequest将失败，因为尝试时X的值将为0，因此将X从1更改为0的修改将失败。原子性规则也会导致ModifyRequest中的所有其他修改失败。
In the multi-master case, it is inevitable that at least some of the changes will be reversed despite the use of the lock. Assuming the changes from A have priority per the conflict resolution algorithm, the value of X should be 0 and the value of Y should be "USER1" The
在多主机情况下，尽管使用了锁，但不可避免的是至少部分更改将被逆转。假设根据冲突解决算法，A的更改具有优先级，则X的值应为0，Y的值应为“USER1”
interesting question is the value of Z at the end of the replication cycle. If it is 42, the atomicity constraint on the change from B has been violated. But for it to revert to its previous value, grouping information must be retained and it is not clear when that information can be safely discarded. Thus, requirement G6 may be violated.
有趣的问题是复制周期结束时Z的值。如果是42，则违反了对B的更改的原子性约束。但要使其恢复到以前的值，必须保留分组信息，并且不清楚何时可以安全地丢弃该信息。因此，可能违反G6要求。
With multi-master replication there are a number of cases where a user or application will complete a sequence of operations with a server but those actions are later "undone" because someone else completed a conflicting set of operations at another server.
对于多主机复制，在许多情况下，用户或应用程序将使用服务器完成一系列操作，但这些操作稍后会“撤消”，因为其他人在另一台服务器上完成了一组冲突的操作。
To some extent, this can happen in any multi-user system. If a user changes the value of an attribute and later reads it back, intervening operations by another user may have changed the value. In the multi-master case, the problem is worsened, since techniques used to resolve the problem in the single-server case won't work as shown in the examples above.
在某种程度上，这可能发生在任何多用户系统中。如果用户更改属性的值并在稍后将其读回，则其他用户的干预操作可能已更改该值。在多主机情况下，问题会更加严重，因为用于解决单服务器情况下的问题的技术不会像上面的示例所示那样起作用。
The major question here is one of intended use. In LDAP standards work, it has long been said that replication provides "loose consistency" among replicas. At several IETF meetings and on the mailing list, usage examples from finance where locking is required have been declared poor uses for LDAP. Requirement G1 is consistent with this history. But if loose consistency is the goal, the locking example above is an inappropriate use of LDAP, at least in a replicated environment.
这里的主要问题是预期用途。在LDAP标准工作中，长期以来人们一直认为复制在副本之间提供了“松散的一致性”。在几次IETF会议和邮件列表上，来自finance的需要锁定的使用示例被宣布为LDAP的糟糕使用。需求G1与此历史一致。但是，如果目标是松散一致性，那么上面的锁定示例是LDAP的不当使用，至少在复制环境中是这样。
The examples above discuss some of the most difficult problems that can arise in multi-master replication. While they can be dealt with, dealing with them is difficult and can lead to situations that are quite confusing to the application and to users.
上面的示例讨论了多主机复制中可能出现的一些最困难的问题。虽然它们是可以处理的，但是处理它们是困难的，并且可能导致应用程序和用户非常困惑的情况。
The common characteristics of the examples are:
这些例子的共同特点是：
- Several directory users/applications are changing the same data.
- 多个目录用户/应用程序正在更改相同的数据。
- They are changing the data before previous changes have replicated.
- 在复制以前的更改之前，他们正在更改数据。
- They are using different directory servers to make these changes.
- 他们正在使用不同的目录服务器进行这些更改。
- They are changing data that are parts of a distinguished name or they are using ModifyRequest to both read and write a given attribute value in a single atomic request.
- 它们正在更改作为可分辨名称一部分的数据，或者使用ModifyRequest在单个原子请求中读取和写入给定属性值。
If any one of these conditions is reversed, the types of problems described above will not occur. There are many useful applications of multi-master directories where at least one of the above conditions does not occur. For cases where all four do occur, application designers should be aware of the possible consequences.
如果上述任何一种情况发生逆转，则不会出现上述类型的问题。多主目录有许多有用的应用程序，其中至少有一种以上情况不会发生。对于这四种情况都发生的情况，应用程序设计者应该意识到可能的后果。
Directories will frequently hold proprietary information. Policy information, name and address information, and customer lists can be quite proprietary and are likely to be stored in directories. Such data must be protected against intercept or modification during replication.
目录通常包含专有信息。策略信息、名称和地址信息以及客户列表可以是非常专有的，并且可能存储在目录中。在复制过程中，必须保护此类数据不被截获或修改。
In some cases, the network environment (e.g., a private network) may provide sufficient data confidentiality and integrity for the application. In other cases, the data in the directory may be public and not require protection. For these reasons data confidentiality and integrity were not made requirements for all replication sessions. But there are a substantial number of applications that will need data confidentiality and integrity for replication, so there is a requirement (S4) that the protocol allow for data confidentiality and integrity in those cases where they are needed. Typically, the policy on the use of confidentiality and integrity measures would be held in the replication agreement per requirement M7.
在某些情况下，网络环境（例如，专用网络）可以为应用程序提供足够的数据机密性和完整性。在其他情况下，目录中的数据可能是公共的，不需要保护。由于这些原因，并非所有复制会话都要求数据的机密性和完整性。但有大量应用程序需要数据机密性和完整性进行复制，因此有一项要求（S4），即协议在需要数据机密性和完整性的情况下允许数据机密性和完整性。通常，关于使用保密性和完整性措施的政策将根据要求M7保存在复制协议中。
This leaves the question of what mechanism(s) to use. While this is ultimately a design/implementation decision, replication across different vendors' directory products is an important goal of the LDAP replication work at the IETF. If different vendors choose to support different data confidentiality and integrity mechanisms, the advantages of a standard replication protocol would be lost. Thus there is a requirement (S6) for mandatory-to-implement data confidentiality and integrity mechanisms.
这就留下了使用什么机制的问题。虽然这最终是一个设计/实施决策，但跨不同供应商目录产品的复制是IETF LDAP复制工作的一个重要目标。如果不同的供应商选择支持不同的数据机密性和完整性机制，那么标准复制协议的优势就会丧失。因此，要求（S6）强制实施数据机密性和完整性机制。
Anonymous replication (requirement S3) is supported since it may be useful in the same sorts of situations where data integrity and data confidentiality protection are not needed.
支持匿名复制（要求S3），因为它在不需要数据完整性和数据机密性保护的相同情况下可能很有用。
In a single-master system, all modifications must originate at the master. The master is therefore a single point of failure for modifications. This can cause concern when high availability is a requirement for the directory system.
在单个主系统中，所有修改必须源自主系统。因此，主机是修改的单点故障。当目录系统需要高可用性时，这可能会引起关注。
One way to reduce the problem is to provide a failover process that converts a slave replica to master when the original master fails. The time required to execute the failover process then becomes a major factor in availability of the system as a whole.
减少问题的一种方法是提供故障转移过程，在原始主副本出现故障时将从副本转换为主副本。然后，执行故障切换过程所需的时间就成为整个系统可用性的一个主要因素。
Factors that designers and implementors should consider when working on failover include:
设计和实现人员在处理故障转移时应考虑的因素包括：
- If the master replica contains control information or meta-data that is not part of the slave replica(s), this information will have to be inserted into the slave that is being "promoted" to master as part of the failover process. Since the old master is presumably unavailable at this point, it may be difficult to obtain this data. For example, if the master holds the status information of all replicas, but each slave replica only holds its own status information, failover would require that the new master get the status of all existing replicas, presumably from those replicas. Similar issues could arise for replication agreements if the master is the only system that holds a complete set.
- 如果主副本包含不属于从属副本的控制信息或元数据，则必须将此信息插入正在作为故障切换过程一部分“升级”为主副本的从属副本中。由于旧主机此时可能不可用，因此可能很难获得此数据。例如，如果主副本保存所有副本的状态信息，但每个从属副本仅保存其自己的状态信息，则故障切换将要求新主副本获取所有现有副本的状态，可能来自这些副本。如果主系统是唯一拥有完整数据集的系统，则复制协议可能会出现类似问题。
- If data privacy mechanisms (e.g., encryption) are in use during replication, the new master would need to have the necessary key information to talk to all of the slave replicas.
- 如果在复制过程中使用数据隐私机制（例如，加密），则新的主副本需要具有必要的密钥信息才能与所有从属副本通信。
- It is not only the new master that needs to be reconfigured. The slaves also need to have their configurations updated so they know where updates should come from and where they should refer modifications.
- 需要重新配置的不仅仅是新主机。从属服务器还需要更新其配置，以便知道更新应该来自何处，以及应该在何处引用修改。
- The failover mechanism should be able to handle a situation where the old master is "broken" but not "dead". The slave replicas should ignore updates from the old master after failover is initiated.
- 故障转移机制应该能够处理旧主机“坏了”而不是“死了”的情况。故障切换启动后，从属副本应忽略来自旧主副本的更新。
- The old master will eventually be repaired and returned to the replica-group. It might join the group as a slave and pick up the changes it has "missed" from the new master, or there might be some mechanism to bring it into sync with the new master and then let it take over as master. Some resynchronization mechanism will be needed.
- 旧主机最终将被修复并返回到副本组。它可能以从机的身份加入组，并从新主机接收它“错过”的更改，或者可能有某种机制使它与新主机同步，然后让它作为主机接管。需要一些再同步机制。
- Availability would be maximized if the whole failover process could be automated (e.g., failover is initiated by an external system when it determines that the original master is not functioning properly).
- 如果整个故障切换过程可以自动化（例如，当外部系统确定原始主机无法正常工作时，故障切换由外部系统启动），则可用性将最大化。
LDAPv3 [RFC2251] declares that some operations are atomic (e.g., all of the modifications in a single ModifyRequest). It also defines several operational attributes that store information about when changes are made to the directory (createTimestamp, etc.) and which ID was responsible for a given change (modifiersName, etc.). Currently, there is no statement in RFC2251 requiring that changes to these operational attributes be atomic with the changes to the data.
LDAPv3[RFC2251]声明某些操作是原子操作（例如，单个ModifyRequest中的所有修改）。它还定义了几个操作属性，这些属性存储有关何时对目录进行更改（createTimestamp等）以及哪个ID负责给定更改（ModifierName等）的信息。目前，RFC2251中没有任何语句要求对这些操作属性的更改与对数据的更改是原子的。
It is RECOMMENDED that this requirement be added during the revision of RFC2251. In the interim, replication SHOULD treat these operations as though such a requirement were in place.
建议在修订RFC2251时增加此要求。在此期间，复制应将这些操作视为有这样的要求。
Authors' Addresses
作者地址
Russel F. Weiser Digital Signature Trust Co. 1095 East 2100 South Suite #201 Salt Lake City, UT 84106
Russel F.Weiser数字签名信托公司，地址：美国犹他州盐湖城201号1095东2100南套房，邮编：84106
Phone: +1 801 326 5421
Fax: +1 801 326 5421
EMail: rweiser@trustdst.com
Phone: +1 801 326 5421
Fax: +1 801 326 5421
EMail: rweiser@trustdst.com
Ellen J. Stokes IBM 11400 Burnet Rd. Austin, TX 78758
德克萨斯州奥斯汀伯内特路11400号埃伦·J·斯托克斯IBM 78758
Phone: +1 512 436 9098
Fax: +1 512 436 1193
EMail: stokese@us.ibm.com
Phone: +1 512 436 9098
Fax: +1 512 436 1193
EMail: stokese@us.ibm.com
Ryan D. Moats Lemur Networks 15621 Drexel Circle Omaha, NE 68135
Ryan D.Moats狐猴网络15621德雷塞尔环奥马哈，东北部68135
Phone: +1 402 894 9456
EMail: rmoats@lemurnetworks.net
Phone: +1 402 894 9456
EMail: rmoats@lemurnetworks.net
Richard V. Huber Room C3-3B30 AT&T Laboratories 200 Laurel Avenue South Middletown, NJ 07748
Richard V.Huber新泽西州劳雷尔大道南米德尔顿200号AT&T实验室C3-3B30室，邮编07748
Phone: +1 732 420 2632
Fax: +1 732 368 1690
EMail: rvh@att.com
Phone: +1 732 420 2632
Fax: +1 732 368 1690
EMail: rvh@att.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。