Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

第 7 章 设计复制过程

复制目录的内容会增加目录服务的可用性和性能。第 4 章 设计目录树 第 6 章 设计目录拓扑 涵盖目录树和目录拓扑的设计。本章解决了数据的物理和地理位置，特别是如何使用复制来确保数据在和需要时可用。
本章讨论使用复制，并提供有关为目录环境设计复制策略的建议。

7.1. 复制简介

复制是自动将目录数据从一个 Red Hat Directory Server 复制到另一个的机制。使用复制时，任何目录树或子树（存储在自己的数据库中）都可在服务器间复制。保存信息的主副本的目录服务器会自动将任何更新复制到所有副本。
复制提供高可用性目录服务，并可分布地理的数据。在实际术语中，复制具有以下优点：
  • 容错和故障转移 - 通过将目录树复制到多个服务器，即使硬件、软件或网络问题也提供了目录服务，即使是硬件、软件或网络问题也会阻止目录客户端应用程序访问特定的目录服务器。客户端被称为另一个目录服务器进行读写操作。
    注意
    写入故障切换只能在多层次复制的情况下实现。
  • 负载平衡 - 在服务器间复制目录树可减少对任何给定计算机的访问负载，从而改进了服务器响应时间。
  • 更高的性能和减少响应时间 - 在用户接近的位置复制目录条目可显著改进了目录响应时间。
  • 本地数据管理 - 复制允许本地拥有和管理信息，同时与整个企业的其他目录服务器共享。

7.1.1. 复制概念

根据以下基本决策，开始规划复制：
  • 要复制哪些信息。
  • 哪些服务器拥有该信息的主副本，或 读写副本。
  • 哪些服务器拥有该信息的只读副本，或 只读副本。
  • 当只读副本收到更新请求时，应该会出现什么情况，即它应该引用该请求的服务器。
在了解目录服务器如何处理这些概念的情况下，无法有效地进行这些决策。例如，决定要复制哪些信息，请注意目录服务器可以处理的最小复制单元。Directory 服务器使用的复制概念提供了一个框架，用于考虑需要做出的全局决策。

7.1.1.1. 复制单元

复制的最小单元是数据库。整个数据库可以复制，但不能在数据库中复制子树。因此，在定义目录树时，总是考虑复制。有关如何设置目录树的详情请参考 第 4 章 设计目录树。
复制机制还需要一个数据库与一个后缀对应。超过两个或多个数据库的后缀（或命名空间）无法复制。

7.1.1.2. 读写和只读副本

参与复制的数据库被定义为 副本。目录服务器支持两种类型的副本：读写和只读。读写副本包含目录信息的主副本，可以更新。只读副本引用对读写副本的所有更新操作。

7.1.1.3. 供应商和消费者

存储复制到不同服务器的副本的服务器称为 供应商。存储从不同服务器复制的副本的服务器称为 消费者。通常说，供应商服务器上的副本是一个读写副本，使用者服务器上的副本是一个只读副本。但是，会有以下例外：
注意
在当前版本的 Red Hat Directory Server 中，复制始终由供应商服务器启动，而不是由消费者启动。这与 Directory 服务器的早期版本不同，允许消费者发起复制（其中使用者服务器可以从供应商服务器检索数据）。

供应商

对于任何特定副本，供应商服务器必须：

  • 响应从目录客户端读取请求和更新请求。
  • 维护副本的状态信息和 changelog。
  • 启动到消费者服务器的复制。
供应商服务器始终负责记录其管理的读写副本的更改，因此供应商服务器会确保将任何更改复制到消费者服务器。

消费者

消费者服务器必须：

  • 响应读取请求。
  • 请参阅对副本的供应商服务器更新请求。
每当消费者服务器收到添加、删除或更改条目的请求时，该请求都会被称为副本的供应商。供应商服务器执行请求，然后复制更改。

Hub 厂商

在级联复制的特殊情况下，hub 供应商必须：

  • 响应读取请求。
  • 请参阅对副本的供应商服务器更新请求。
  • 启动到消费者服务器的复制。
有关级联复制的详情请参考 第 7.2.3 节 “cascading Replication”。

7.1.1.4. 复制和更改日志

每个供应商服务器均有 changelog。更改日志是副本中发生的修改记录。然后，供应商服务器会在消费者服务器上回放这些修改，或当多层次复制时在其他供应商上回放这些修改。
修改条目时，会在 changelog 中记录描述执行的 LDAP 操作的更改记录。
changelog 的大小使用两个属性维护，即 nsslapd-changelogmaxage 或 nsslapd-changelogmaxentries。这些属性会修剪旧的 changelogs，以合理的更改日志大小。

7.1.1.5. 复制协议

目录服务器使用复制协议来定义复制。复制协议描述了单个供应商和单一消费者之间的复制。该协议是在供应商服务器上配置的。它标识：
  • 要复制的数据库。
  • 将数据推送到的使用者服务器。
  • 复制发生的时间。
  • 供应商服务器必须使用的 DN 来绑定（称为 供应商绑定 DN）。
  • 连接的保护方式（TLS、启动 TLS、客户端验证、SASL 或简单身份验证）。
  • 任何不会被复制的属性（请参阅 第 7.3.2 节 “使用 Fractional Replication 复制复制所选属性”）。

7.1.2. 数据一致性

一致性指的是复制数据库的内容在给定时间点上如何相互匹配。在服务器间复制的部分是调度更新。供应商服务器始终决定消费者服务器何时需要更新并启动复制。
目录服务器提供在一周中的特定时间或一天保留副本始终同步或调度更新的选项。
保持副本持续同步的优点是它提供更好的数据一致性。成本是来自频繁更新操作的网络流量。这个解决方案是在以下情况下的最佳选择：
  • 服务器之间有可靠、高速连接。
  • 目录服务服务的客户端请求主要是搜索、读取和写入和比较操作，以及相对较少的更新操作。
如果数据一致性程度较低，请选择最适合网络模式的更新频率，或降低对网络流量的影响。有些情况下，有计划更新而不是持续更新是最佳解决方案：
  • 可用网络连接不可靠或间歇性。
  • 目录服务服务的客户端请求主要更新操作。
  • 需要降低通信成本。
在多层次复制的情况下，每个供应商的副本都表示 松散一致，因为在任何给定时间，存储在每个供应商中的数据中可能存在差异。这的确如此，即使副本持续同步，原因如下：
  • 在供应商间传播更新操作时会有一个延迟。
  • 提供服务更新操作的供应商不会等待第二个供应商在向客户端返回"成功"消息前进行验证。
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat, Inc.