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

第 6 章 设计复制过程

复制目录信息会增加目录的可用性和性能。设计复制过程，以确保数据在何时和需要的位置可用。

6.1. 复制简介
复制链接

复制是自动将目录数据从一个目录服务器复制到另一个目录服务器的机制。使用复制时，存储在自己的数据库(副本)中的任何目录树或子树都可以在服务器之间复制。保存信息的主副本的服务器会自动将任何更新复制到所有副本。

复制提供高可用性目录服务，并可在地理上分发数据。以下是复制优点列表：

  • 容错和故障转移

    将目录树复制到多个服务器可确保您的目录可用，即使客户端应用程序因为硬件、软件或网络问题无法访问特定的目录服务器。客户端被称为另一个目录服务器进行读写操作。

    注意

    只有通过 多层次复制复制功能，才能添加、修改和删除 操作的故障转移。

  • 负载平衡

    在服务器间复制目录树可减少任何给定服务器上的访问负载，从而改进了服务器响应时间。

  • 更高的性能

    将目录条目复制到用户接近的位置可提高目录服务器性能。

  • 本地数据管理

    通过复制，您可以在本地拥有和管理信息，同时与整个企业中的其他目录服务器共享。

6.1.1. 复制概念
复制链接

在考虑实施复制时，回答以下基本问题：

  • 您需要复制哪些信息？
  • 哪些服务器持有该信息的主副本或供应商副本？
  • 哪些服务器持有该信息的只读副本或消费者副本。
  • 当消费者副本从客户端应用程序接收 修改 请求时会发生什么？哪些服务器必须重定向到哪个服务器？

了解提供了解目录服务器如何实现复制的概念：

6.1.1.1. replica
复制链接

副本 是参与复制的数据库。目录服务器支持以下类型的副本：

供应商副本（读写）
包含目录数据的主副本的读写数据库。只有供应商副本处理 修改 目录客户端的请求。
消费者副本（只读）
包含供应商副本上保存信息的另一副本的只读数据库。消费者副本可以处理目录客户端的搜索请求，但引用 修改 对供应商副本的请求。

目录服务器可以在复制中管理具有不同角色的多个数据库。例如，您可以在供应商副本中存储 dc=accounting,dc=example,dc=com 后缀，以及消费者副本中的 dc=sales,dc=example,dc=com 后缀。

6.1.1.2. 复制单元
复制链接

复制的最小单元是后缀（命名空间）。复制机制要求一个后缀对应于一个数据库。目录服务器无法使用自定义分发逻辑复制通过两个或多个数据库分发的后缀。

6.1.1.3. 供应商和消费者
复制链接

供应商服务器
供应商服务器是将更新复制到其他服务器的服务器。供应商服务器维护一个更改日志，其中包含每个更新操作的记录。
消费者服务器
消费者服务器是一个从其他服务器接收更新的服务器。

在以下情况下，服务器可以同时扮演供应商和消费者的角色：

  • 在级联复制中，当某些服务器扮演 hub 服务器的角色时。如需更多信息，请参阅 删除复制。
  • 在多层次复制中，当多个服务器管理供应商读写副本时。每台服务器从其他服务器发送和接收更新。如需更多信息，请参阅 多层次复制。
注意

在 Red Hat Directory Server 中，供应商服务器总是启动复制，而不是消费者。

供应商服务器必须执行以下操作：

  • 响应从目录客户端 读取 请求和 更新请求。
  • 维护副本的状态信息和更改日志。供应商服务器始终负责记录对其管理的读写副本所做的更改。这样可确保任何更改被复制到消费者服务器中。
  • 启动到消费者服务器的复制。

消费者服务器必须执行以下操作：

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

在级联复制的特殊情况下，hub 服务器执行以下操作：

  • 响应 读取 请求。
  • 请参阅对供应商服务器的更新请求。
  • 启动到消费者服务器的复制。

6.1.1.4. 变更日志
复制链接

每个供应商服务器均维护 更改日志。changelog 是供应商副本中发生的修改记录。供应商服务器将这些修改推送到存储在其他服务器上的副本。

添加、修改或删除条目时，目录服务器会在 changelog 文件中记录执行的 LDAP 操作。

更改日志仅用于服务器内部使用。如果您的应用程序需要读取更改日志，则需要使用 Retro Changelog 插件来向后兼容。

有关 changelog 属性的详情，请参考 cn=changelog,cn=database_name,cn=ldbm database,cn=plugins,cn=config 下的数据库属性。

6.1.1.5. 复制协议
复制链接

服务器使用复制协议来定义如何在两个服务器之间执行复制。复制协议描述了一个供应商 和一个 消费者之间的复制。协议在供应商服务器上配置，并确定以下信息：

  • 要复制的数据库。
  • 推送数据的使用者服务器。
  • 复制可能会发生的时间。
  • 供应商服务器必须在消费者上绑定的 DN 和凭证，称为 Replication Manager 条目或 供应商绑定 DN。
  • 如何保护连接，例如 TLS、StartTLS、客户端身份验证、SASL 或简单身份验证。
  • 要复制的属性。有关部分复制的详情，请参阅 Fractional 复制。

6.1.2. 数据一致性
复制链接

数据一致性指的是复制数据库的内容在给定时间点上如何相互匹配。供应商决定消费者何时必须更新，并启动复制。复制只能在消费者初始化后启动。

目录服务器始终在一周的一天或一天的特定时间保持同步或调度更新。

持续同步副本

持续同步的副本提供更好的数据一致性，但它们会因为频繁更新而增加网络流量。

在以下情况下使用持续同步的副本：

  • 在服务器间有可靠、高速的连接。
  • 您的客户端应用程序主要发送 搜索，读取，并与目录服务器 进行比较，仅发送几个 更新操作。

用户计划更新

如果您的目录可能具有较低级别的数据一致性，并且您希望降低网络流量的影响，请选择调度更新。

在以下情况下使用调度的更新：

  • 您有不可靠或定期可用的网络连接。
  • 客户端应用程序主要向 目录服务器 发送添加和修改操作。
  • 您需要降低连接成本。

multi-supplier 复制中的数据一致性

当您有多层次复制时，每个供应商都有松散一致的副本，因为在任何给定时间，供应商在存储的数据中可能会存在差异，即使副本不断同步。

松散一致性的主要原因如下：

  • 在供应商之间传播 修改操作 具有延迟。
  • 服务 修改操作 的供应商不会等待第二个供应商在向客户端返回"成功"消息前进行验证。
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat