Search

Chapter 6. Designing the replication process

download PDF

Replicating the directory information increases the availability and performance of the directory. Design the replication process to ensure the data is available when and where it is needed.

6.1. Introduction to replication

Replication is the mechanism that automatically copies directory data from one Directory Server to another. Using replication, any directory tree or sub-tree stored in its own databases (replicas) can be copied between servers. The server holding the main copy of the information automatically copies any updates to all replicas.

Replication provides a high-availability directory service and can distribute data geographically. The following is a list of replication benefits:

  • Fault tolerance and failover

    Replicating directory trees to multiple servers ensures that your directory is available even if client applications cannot access a particular Directory Server because of hardware, software, or network problems. Clients are referred to another Directory Server for read and write operations.

    Note

    Failover for add, modify, and delete operations is possible only with multi-supplier replication.

  • Load balancing

    Replicating the directory tree across servers reduces the access load on any given server resulting in improved server response times.

  • Higher performance

    Replicating directory entries to a location close to users improves Directory Server performance.

  • Local data management

    With replication, you can own and manage information locally while sharing it with other Directory Server across the enterprise.

6.1.1. Replication concepts

When you consider implementing replication, answer the following fundamental questions:

  • What information do you need to replicate?
  • Which servers hold the main copy, or supplier replica, of that information?
  • Which servers hold the read-only copy, or consumer replica, of that information.
  • What happens when a consumer replica receives a modify request from a client application? To which server must the request be redirected?

Learn about the concepts that provide understanding of how Directory Server implements replication:

6.1.1.1. Replica

A replica is a database that participates in replication. Directory Server supports the following types of replicas:

Supplier replica (read-write)
A read-write database that contains the main copy of the directory data. Only the supplier replica processes modify requests from directory clients.
Consumer replica (read-only)
A read-only database that contains another copy of the information held on the supplier replica. A consumer replica can process search requests from directory clients but refers modify requests to the supplier replica.

Directory Server can manage several databases with different roles in replication. For example, you can have the dc=accounting,dc=example,dc=com suffix stored in a supplier replica, and the dc=sales,dc=example,dc=com suffix in a consumer replica.

6.1.1.2. Replication unit

The smallest unit of replication is a suffix (namespace). The replication mechanism requires that one suffix corresponds to one database. Directory Server cannot replicate a suffix that is distributed over two or more databases using custom distribution logic.

6.1.1.3. Suppliers and consumers

Supplier server
A supplier server is a server that replicates updates to other servers. The supplier server maintains a changelog that contains records of each update operation.
Consumer server
A consumer server is a server that receives updates from other servers.

A server can play the role of a supplier and consumer at the same time in the following situations:

  • In cascading replication, when some servers play the role of a hub server. For more information, see Cascading replication.
  • In multi-supplier replication, when several servers manage the supplier read-write replica. Each server sends and receives updates from other servers. For more information, see Multi-supplier replication.
Note

In Red Hat Directory Server, the supplier server always initiates replication, never the consumer.

The supplier server must perform the following actions:

  • Respond to read requests and update requests from directory clients.
  • Maintain state information and a changelog for the replica. The supplier server is always responsible for recording changes made to the read-write replicas that it manages. This ensures that any changes are replicated to consumer servers.
  • Initiate replication to consumer servers.

The consumer server must perform the following actions:

  • Respond to read requests.
  • Refer update requests to a supplier server for the replica. When a consumer server receives a request to add, delete, or change an entry, the request is referred to a supplier server. The supplier server then performs the request and replicates these changes.

In the special case of cascading replication, the hub server performs the following actions:

  • Respond to read requests.
  • Refer update requests to a supplier server.
  • Initiate replication to consumer servers.

6.1.1.4. Changelog

Every supplier server maintains a changelog. The changelog is a record of the modifications that have occurred on a supplier replica. The supplier server pushes these modifications to the replicas stored on other servers.

When an entry is added, modified, or deleted, Directory Server records the performed LDAP operation in the changelog file.

The changelog is intended only for internal use by the server. If you have applications that need to read the changelog, you need to use the Retro Changelog plug-in for backward compatibility.

For details about changelog attributes, refer to Database attributes under cn=changelog,cn=database_name,cn=ldbm database,cn=plugins,cn=config.

6.1.1.5. Replication agreements

Servers use replication agreements to define how replication is performed between two servers. A replication agreement describes replication between one supplier and one consumer. The agreement is configured on the supplier server and identifies the following information:

  • The database to replicate.
  • The consumer server to which the data is pushed.
  • The time when replication can occur.
  • The DN and credentials the supplier server must use to bind on the consumer, called the Replication Manager entry or supplier bind DN.
  • How the connection is secured, for example, TLS, StartTLS, client authentication, SASL, or simple authentication.
  • Attributes that you want to replicate. For more details about fractional replication, see Fractional replication.

6.1.2. Data consistency

Data consistency refers to how closely the contents of replicated databases match each other at a given time. A supplier determines when consumers must be updated, and initiates replication. Replication can start only after consumers have been initialized.

Directory Server can always keep replicas synchronized or schedule updates for a particular time of day or day in a week.

Constantly synchronized replicas

Constantly synchronized replicas provide better data consistency, however they increase network traffic because of frequent updates.

Use constantly synchronized replicas when:

  • You have a reliable, high-speed connection between servers.
  • Your client applications mainly send search, read,and compare to Directory Server and only a few update operations.

Schedule updates of consumers

Choose to schedule updates if your directory can have a lower level of data consistency and you want to lower the impact on network traffic.

Use scheduled updates when:

  • You have unreliable or periodically available network connections.
  • Client applications mainly send add and modify operations to Directory Server.
  • You need to reduce the connection costs.

Data consistency in multi-supplier replication

When you have multi-supplier replication, each supplier has loosely consistent replicas, because at any given time, suppliers can have differences in the stored data, even if the replicas are constantly synchronized.

The main reasons for the loose consistency are the following:

  • The propagation of modify operations between suppliers has latency.
  • The supplier that serviced the modify operation does not wait for the second supplier to validate it before returning an "operation successful" message to the client.

6.2. Common replication scenarios

You can use the following common scenarios to build the replication topology that best suits your needs:

6.2.1. Single-supplier replication

In the single-supplier replication scenario, a supplier server maintains the main copy of the directory data (read-write replica) and sends updates of this data to one or more consumer servers. All directory modifications occur on the read-write replica on the supplier server, and the consumer servers contain read-only replicas of the data.

The supplier server maintains a changelog that records all the changes made to the supplier replica.

The following diagram shows the single-supplier replication scenario:

Figure 6.1. Single-supplier replication

dg designing replication1

The total number of consumer servers that a single supplier server can manage depends on the speed of the networks and the total number of entries that are modified on a daily basis.

6.2.2. Multi-supplier replication

In a multi-supplier replication environment, main copies of the same information can exist on multiple servers, and the directory data can be updated simultaneously in different locations. The changes that occur on each server are replicated to the other servers meaning that each server functions as both a supplier and a consumer.

When the same data is modified on multiple servers, replication conflicts occur. Using a conflict resolution procedure, Directory Server uses the most recent change as the valid one.

In a multi-supplier environment, each supplier needs to have replication agreements that point to consumers and other suppliers. For example, you configure replication with two suppliers, Supplier A and Supplier B, and two consumers, Consumer C and Consumer D. In addition, you decide that one supplier updates only one consumer. On Supplier A, you create a replication agreement that points to Supplier B and Consumer C. On Supplier B, you create a replication agreement that points to Supplier A and Consumer D. The following diagram illustrates the replication agreements:

Figure 6.2. Multi-supplier replication with two suppliers

dg designing replication2
Note

Red Hat Directory Server supports a maximum of 20 supplier servers in any replication environment and an unlimited number of hub and consumer servers.

Using many suppliers requires creating a range of replication agreements. In addition, each supplier can be configured in different topologies meaning that your Directory Server environment can have 20 different directory trees and even schema differences. Many other variables may have a direct impact on the topology selection.

Suppliers can send updates to all other suppliers or to some subset of suppliers. When updates are sent to all suppliers, changes are propagated faster and the overall scenario has better failure tolerance. However, it increases the complexity of supplier configuration and introduces high network and high server demand. Sending updates to a subset of suppliers is much simpler to configure and reduces the network and server loads, but increases the risk of data loss if multiple server failures occur.

Fully connected mesh topology

The following diagram shows a fully connected mesh topology where four supplier servers replicate data to all other supplier servers. In total, twelve replication agreements exist between the four supplier servers because one replication agreement describes relations between only one supplier and one consumer.

dg designing replication3

If you have 20 suppliers, then you need to create 380 replication agreements in total (20 suppliers with 19 agreements each).

If the possibility of two or more servers failing at the same time is small or connection between certain suppliers is better, consider using a partly connected topology.

Partly connected topology

The following diagram shows a topology where each supplier server replicates data to two supplier servers. Only eight replication agreements exist between the four supplier servers compared to the previous example topology.

dg designing replication4

6.2.3. Cascading replication

In a cascading replication scenario, a hub server receives updates from a supplier server and sends those updates to consumer servers. The hub server is a hybrid, because it holds a read-only replica, like a typical consumer server, and it also maintains a changelog like a typical supplier server.

Hub server forward the supplier data to consumers and refer update requests from directory clients to suppliers.

The following diagram shows the cascading replication scenario:

Figure 6.3. Cascading replication scenario

dg designing replication5

The following diagram shows how replicas are configured on each server (read-write or read-only) and which servers maintain the changelog.

Figure 6.4. Replication traffic and changelogs in cascading replication

dg designing replication6

Cascading replication is useful in the following cases:

  • To balance heavy traffic loads. Because the suppliers in a replication topology manage all update traffic, it may put them under a heavy load to support replication traffic to consumers as well. You can redirect replication traffic to a hub that can service replication updates to a large number of consumers.
  • To reduce connection costs by using a local hub supplier in geographically distributed environments.
  • To increase the performance of your directory service. If you direct all read operations to the consumers, and all update operations to the supplier, you can remove all of the indexes (except system indexes) from your hub server. This will dramatically increase the speed of replication between the supplier and the hub server.

6.2.4. Mixed scenarios

Any of the replication scenarios can be combined to suit the needs of the network and directory environment. One common combination is to use a multi-supplier configuration with a cascading configuration.

The following diagram shows an example topology for a mixed scenario:

Figure 6.5. Combined multi-supplier and cascading replication

dg designing replication7

6.3. Defining a replication strategy

You can determine your replication strategy based on the services you want to provide. The following are common replication strategies that you can implement:

  • If high availability is the primary concern, create a data center with multiple Directory Servers on a single site. Single-supplier replication provides read-failover, while multi-supplier replication provides write-failover.

    For more details, see Using replication for high availability.

  • If local availability is the primary concern, use replication to distribute data geographically to Directory Servers in local offices around the world. You can maintain the main copy of all information in a single location, such as the company headquarters, or each local site can manage the parts of the directory that are relevant to them.

    For more details, see Using replication for local availability.

  • To balance the load of requests that Directory Server manages and avoid network congestion, use replication configuration for load balancing.

    For more details, see Using replication for load balancing.

  • If you use multiple consumers for different locations or sections of the company or if some servers are insecure, then use fractional replication to exclude sensitive or rarely modified information to maintain data integrity without compromising sensitive information.

    For more details, see Fractional replication.

  • If the network is stretched across a wide geographical area with multiple Directory Servers at multiple sites and local data suppliers connected by multi-supplier replication, use the replication configuration for a wide-area network.

    For more details, see Replication across a wide-area network.

To determine the replication strategy, start by performing a survey of the network, users, applications, and how they use the directory service.

6.3.1. Performing a replication survey

Gather information about the network quality and usage to help define the replication strategy:

  • The quality of the LANs and WANs that connect different buildings or remote sites and the amount of available bandwidth.
  • The physical location of users, how many users are at each site, and their usage patterns for understanding how they intend to use the directory service.

    A site that manages human resource databases or financial information usually creates a heavier load on the directory than a site containing engineering staff that uses the directory only for telephone book purposes.

  • The number of applications that access the directory and the relative percentage of read, search, and compare operations to write operations.

    If the messaging server uses the directory, find out how many operations it performs for each email message it handles. Other products that use the directory are typically products such as authentication applications or meta-directory applications. For each application, determine the type and frequency of operations that are performed in the directory.

  • The number and size of the entries stored in the directory.

6.3.2. Replication resource requirements

Replication requires resources. Consider the following resource requirements when defining the replication strategy:

Disk usage
On supplier servers, Directory Server writes a changelog after each update operation. Therefore, supplier servers that receive many update operations have higher disk usage.
Server threads
Each replication agreement creates a dedicated threads, and the CPU load depends on the replication throughput.
File descriptors
A server uses one file descriptor for a changelog and one file descriptor for each replication agreement.

6.3.3. Managing disk space required for multi-supplier replication

In multi-supplier topologies, suppliers maintain additional logs required for replication, including the changelog of the directory edits, state information for updated entries, and tombstone entries for deleted entries. Because these log files can become very large, you must periodically clean up these files to avoid unnecessary usage of the disk space.

On each server, you can use the following attributes to configure the replication logs maintenance in a replicated environment:

  • The nsslapd-changelogmaxage attribute sets the maximum age of entries in the changelog. Once an entry is older than the maximum age value, Directory Server deletes the entry. Setting the maximum age of entries keeps the changelog from growing indefinitely.
  • The nsslapd-changelogmaxentries attribute sets the maximum number of entries that the changelog can contain. Note that the nsslapd-changelogmaxentries value must be large enough to contain a complete set of directory information. Otherwise, multi-supplier replication may function with issues.
  • The nsDS5ReplicaPurgeDelay sets the maximum age of tombstone (deleted) entries and state information in the changelog. Once a tombstone or state information entry is older than that age, Directory Server deletes the entry. The nsDS5ReplicaPurgeDelay value applies only to tombstone and state information entries, while nsslapd-changelogmaxage applies to every entry in the changelog, including directory modifications.
  • The nsDS5ReplicaTombstonePurgeInterval attribute sets how often the server runs a purge operation to clean the tombstone and state entries out of the changelog. Ensure that the maximum age is longer than the longest replication update schedule. Otherwise, multi-supplier replication can have issues when updating replicas.

6.3.4. Using replication for high availability

Use replication to prevent directory unavailability when a single server fails. At a minimum, replicate the local directory tree to at least one backup server. How often you replicate for fault tolerance depends on your requirements. However, base this decision on the quality of the hardware and networks used by your directory. Unreliable hardware requires more backup servers.

Important

Do not use replication as a replacement for a regular data backup policy because replication and backups have different purposes. For information on backing up the directory data, see Backing up and restoring Red Hat Directory Server.

You can choose the following strategies to prevent directory unavailability:

LDAP client applications are usually configured to search only one LDAP server. If you do not have a custom client application to rotate through LDAP servers located at different DNS hostnames, you can only configure your LDAP client application to look at a single DNS hostname for Directory Server. Therefore, you may need to use either DNS round-robins or network sorts to provide failover to your backup Directory Server.

6.3.5. Using replication for local availability

You may need to use replication for local availability depending on the quality of your network and if your data is mission-critical.

Use replication for local availability for the following reasons:

  • You require a local main copy of the data.

    Large, multinational enterprises may need to maintain directory information of interest only to the employees in a certain country. In addition, having a local main copy of the data is important to any enterprise where interoffice politics dictate to control the data at a divisional or organizational level.

  • You have unreliable or intermittently available network connections.

    International networks have unreliable WANs that cause intermittent network connections.

  • You have periodic, extremely heavy network loads that impact Directory Server performance.

    Enterprises with aging networks may experience heavy network loads during normal business hours.

  • You want to reduce the network load and the workload on the suppliers.

    Even if the network is reliable and available, you may want to reduce network costs.

6.3.6. Using replication for load balancing

One of the main reasons to replicate directory data is to balance the workload of your network and to improve the directory performance.

As directory entries are usually 1 KB in size, every directory search adds approximately 1 KB to your network load. If your directory users perform ten directory searches per day, then the increased network load for every directory user is around 10 KB per day. If you have a slow, heavily loaded, or unreliable WAN, you may need to replicate your directory tree to a local server.

However, determine if locally available data is worth the cost of the increased network load caused by replication. If you replicate an entire directory tree to a remote site, you potentially add a larger load on your network in comparison to the traffic that results from users' searches. This is especially true if your directory changes frequently, yet you have only a few users at the remote site who perform a few directory searches per day.

The following table compares the load impact of replicating a directory with one million entries, where 100,000 of the entries undergo daily change, with the load impact of having a small remote site of 100 employees that perform 10 searches per day each.

Table 6.1. Impact of replication and remote searches on the network
Load typeAccess/dayAverage entry sizeLoad

Replication

100,000

1KB

100MB/day

Remote searches

1,000

1KB

1MB/day

A compromise between making data available to local sites without overloading the network is to use scheduled replication. For more information on data consistency and replication schedules, see Data consistency.

6.3.6.1. Example of network load balancing

This example describes an enterprise that has offices in New York (NY) and Los Angeles (LA), and each office manages a separate sub-tree.

The following diagram show how the enterprise manages the sub-trees:

Figure 6.6. The enterprise NY and LA sub-trees

dg designing replication8

Each office contains a high-speed network, but the connection between the two cities is unreliable. To balance the network load, use the following strategy:

  • Select one server in each office to be the supplier server for the locally managed data.

    Replicate locally managed data from that supplier to the corresponding supplier server in the remote office. When you have main copy of the data in each location, users do not perform update and search operations over the unreliable connection. As a result, performance is optimized.

  • Replicate the directory tree on each supplier server (including data supplied from the remote office) to at least one local Directory Server to ensure availability of the directory data.
  • Configure cascading replication in each location with an increased number of consumers dedicated to search on the local data to provide further load balancing.

    The NY office generates more NY specific searches than LA specific searches. The example shows the NY office with three NY data consumers and one LA consumer. The LA office has three LA data consumers and one NY data consumer.

Figure 6.7. Example of load balancing for the enterprise

dg designing replication9

6.3.6.2. Example of load balancing for improved performance

This example describes an enterprise that has the following characteristics:

  • The directory includes 1,500,000 entries in support of 1,000,000 users.
  • Each user performs ten directory searches per day.
  • A messaging server handles 25,000,000 mail messages per day and performs five directory searches for every mail message.
  • Users are spread across four time zones.

This equates to 135,000,000 directory searches per day in total:

1,000,000 users x 10 searches = 10,000,000 user searches per day

25,000,000 mails x 5 searches = 125,000,000 mail searches per day

10,000,000 + 125,000,000 = 135,000,000 all searches per day

With an eight-hour business day and users spread across four time zone, the peak usage across four time zones extends to 12 hours. Therefore, the Directory Server must support 135,000,000 directory searches in a 12-hour day. This equates to 3,125 searches per second (135,000,000 / (60*60*12)).

If the hardware that runs Directory Server supports 500 reads per second, you must use at least six or seven Directory Servers to support this load. For enterprises with a million directory users, add more Directory Servers for local availability purposes.

In such a scenario, you can use the following replication strategy:

  • Place two Directory Servers in a multi-supplier configuration in one city to handle all write traffic.

    This configuration assumes that you want a single point of control for all directory data.

  • Use supplier servers to replicate to one or more hubs.

    Point the read, search, and compare requests at the consumers freeing the suppliers to handle only write requests. For more information about hubs, see Cascading-replication.

  • Use the hub to replicate to local sites throughout the enterprise.

    Replicating to local sites helps balance the load on your servers and your network, and ensures high availability of directory data.

  • At each site, replicate at least once to ensure high availability, at a minimum for read operations.

    Use DNS sort to ensure that local users always find a local Directory Server they can use for directory searches.

6.3.6.3. Example replication strategy for a small site

The example enterprise has the following characteristics:

  • The entire enterprise is contained within a single building.
  • The building has a very fast (100 Mb per second) and lightly used network.
  • The network is very stable, and the server hardware and OS platforms are reliable.
  • A single server can handle the load easily.

With such conditions, you need to replicate at least one time to ensure availability when you shut down the primary server for maintenance or hardware upgrades. Also, set up a DNS round-robin to improve LDAP connection performance when one of the Directory Servers becomes unavailable.

6.3.6.4. Example replication strategy for a large site

The example enterprise from Example replication strategy for a small site has grown to a larger one and now has the following characteristics:

  • The company is contained within two separate buildings, Building A and Building B.
  • The connection between buildings is slow and very busy during normal business hours.
  • Each building has a very fast (100 Mb per second) and lightly used network.
  • The network within each building is very stable, and the server hardware and OS platforms are reliable.
  • A single server can handle the load within one building easily.

With such conditions, your replication strategy contains the following steps:

  • Choose a single server in one of the two buildings to contain the main copy of the directory data.

    Place the server in the building that contains the largest number of people responsible for the main copy of the directory data, for example, Building A.

  • Replicate at least once within Building A for high availability of directory data.

    Use a multi-supplier replication configuration to ensure write-failover.

  • Create two replicas in the second Building B.
  • If you do not need close consistency between the supplier and consumer servers, schedule replication to occur only during off-peak hours.

6.3.7. Fractional replication

With fractional replication, you can choose a set of attributes that Directory Server does not replicate from a supplier to a consumer or another supplier. Therefore, a database can be replicated without replicating all the information that the database contains.

Fractional replication is enabled and configured per replication agreement. Directory Server applies the exclusion of attributes equally to all entries. The excluded attributes always have no value on consumers. Therefore, a client performing a search against the consumer server never sees the excluded attributes, even if search filters explicitly specify these attributes.

Use fractional replication in the following situations:

  • A consumer server is connected using a slow network. Excluding rarely changed attributes or larger attributes, such as jpegPhoto, decreases network traffic.
  • A consumer server is placed on an untrusted network such as the public Internet. Excluding sensitive attributes, such as telephone numbers, provides an extra level of protection that ensures no access to the sensitive attributes even if the server access control measures are defeated or the machine is compromised by an attacker.

6.3.8. Replication across a wide area network

Wide area networks (WAN) typically have higher latency, a higher bandwidth-delay product, and lower speeds than local area networks. Directory Server supports efficient replication when a supplier and consumer are connected using a wide-area network.

Previously, the replication protocols that Directory Server used were highly latency-sensitive, because the supplier sent only one update operation and then waited for a response from the consumer. This led to reduced throughput with higher latencies.

Currently, a supplier sends many updates and entries to the consumer without waiting for a response, and the replication throughput is similar to throughput of a local area network.

Consider the following performance and security issues when using a WAN:

  • Use the Transport Layer Security (TLS) protocol to secure replication performed across a public network, such as the Internet.
  • Use a T1 or faster internet connection for the network.
  • Avoid constant synchronization between the servers when creating agreements for replication over a WAN. Replication traffic can consume a large portion of the bandwidth and slow down the overall network and internet connections.

6.4. Using replication with other Directory Server features

To design the replication strategy better, learn about the interaction between replication and other Directory Server features.

6.4.1. Replication and access control

The directory stores access control instructions (ACIs) as attributes of entries and Directory Server replicates these ACIs together with other directory content. For example, to restrict access to the directory from a certain host, use only host-specific settings in the ACI. Otherwise, when the ACI is replicated to other servers, the access to the directory will be denied on all servers because Directory Server evaluates ACIs locally.

For more information about designing access control for the directory, see Designing access control.

6.4.2. Replication and Directory Server plug-ins

Replication works with most of the plug-ins delivered with Directory Server. However, the following plug-ins have limitations and exceptions in multi-supplier environments:

  • Attribute Uniqueness plug-in

    The Attribute Uniqueness plug-in validates the uniqueness of attribute values added to entries only on a local server. For example, a company requires the mail attribute to be unique for user entries. When two different users are added with the same value for the mail attribute on two different supplier servers at the same time, Directory Server adds these users to the directory because no naming conflict and, as a result, no replication conflict occurs. The Attribute Uniqueness plug-in does not check replicated changes and, as a result, the mail attribute value becomes non-unique in the directory.

  • Referential Integrity plug-in

    Referential integrity works with multi-supplier replication when it is enabled on only one supplier in the multi-supplier set. This ensures that referential integrity updates occur on only one of the supplier servers and are propagated to the other servers.

  • Auto Membership and MemberOf plug-ins

    For these two plug-ins to work correctly in a replication environment, configure the plug-ins to perform updates locally on each server.

Note

By default, plug-ins are disabled, and you must enable them manually.

6.4.4. Schema replication

In a replicated environment, the schema must be consistent across all of the servers that participate in replication. To ensure schema consistency, make schema modifications only on a single supplier server.

If you configured replication between servers, schema replication occurs by default.

Standard schema

Directory Server uses the following scenario for the standard schema replication:

  1. Before pushing data to consumer servers, the supplier server checks if its version of the schema is the same as the version of the schema held on the consumer servers.
  2. If the schema entries on both the supplier and the consumers are the same, the replication operation proceeds.
  3. If the supplier schema version is more recent than the consumer schema version, the supplier server replicates its schema to the consumer before proceeding with the data replication.
  4. If the supplier schema version is older than the consumer schema version, the replication may fail or the server may return errors during replication because the schema on the consumer cannot support the new data. Therefore, never update the schema on a consumer server. You must maintain the schema only on a supplier server in a replicated topology.

Directory Server replicates changes to the schema made by using dsconf command, the web console, LDAP modify operations, or made directly to the 99user.ldif file.

If you make schema modifications on two supplier servers, consumers receive the data from the two suppliers, each with a different schema. The consumer applies the modifications of the supplier that has the more recent schema version. In this situation, the schema of the consumers always differs from one of the suppliers. To avoid this, always make sure you make schema modifications on one supplier only.

You do not need to create special replication agreements to replicate a schema. However, the same Directory Server can hold supplier and consumer replicas. Therefore, always identify the server that functions as a supplier for the schema, and then set up replication agreements between this supplier and all other servers in the replication environment that will function as consumers for the schema information.

For more information on standard schema files, see Standard schema.

Custom schema

Directory Server replicates only a custom schema to all consumers if you use the standard 99user.ldif file as your custom schema. Directory Server does not replicate other custom schema files, or changes to these files, even if you made changes through the web console or the dsconf command.

If you use other custom files, you must copy these files to all servers in your topology manually after making changes on the supplier.

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.