7.4. Using Replication with Other Directory Server Features

Replication interacts with other Directory Server features to provide advanced replication features. The following sections describe feature interactions to better design the replication strategy.

7.4.1. Replication and Access Control

The directory service stores ACIs as attributes of entries. This means that the ACI is replicated together with other directory content. This is important because Directory Server evaluates ACIs locally.

For more information about designing access control for the directory, see Chapter 9, Designing a Secure Directory.

7.4.2. Replication and Directory Server Plug-ins

Replication works with most of the plug-ins delivered with Directory Server. There are some exceptions and limitations in the case of multi-master replication with the following plug-ins:

Attribute Uniqueness Plug-in
The Attribute Uniqueness Plug-in validate attribute values added to local entries to make sure that all values are unique. However, this checking is done directly on the server, not replicated from other suppliers. For example, Example Corp. requires that the mail attribute be unique, but two users are added with the same mail attribute to two different supplier servers at the same time. As long as there it no a naming conflict, then there is no replication conflict, but the mail attribute is not unique.
Referential Integrity Plug-in
Referential integrity works with multi-master replication, provided that this plug-in is enabled on only one supplier in the multi-master set. This ensures that referential integrity updates occur on only one of the supplier servers and propagated to the others.

NOTE

By default, these plug-ins are disabled, and they must be manually enabled.

7.4.3. Replication and Database Links

With chaining to distribute directory entries, the server containing the database link references a remote server that contains the actual data. In this environment, the database link itself cannot be replicated. However, the database that contains the actual data on the remote server can be replicated.

Do not use the replication process as a backup for database links. Database links must be backed up manually. For more information about chaining and entry distribution, see Chapter 6, Designing the Directory Topology.

Figure 7.10. Replicating Chained Databases

7.4.4. Schema Replication

In all replication scenarios, before replicating data to consumer servers, the supplier server checks whether its own version of the schema is synchronized with the version of the schema stored on the consumer servers. The following conditions apply:

If the schema entries on both supplier and consumers are the same, the replication operation proceeds.
If the version of the schema on the supplier server is more recent than the version stored on the consumer, the supplier server replicates its schema to the consumer before proceeding with the data replication.
If the version of the schema on the supplier server is older than the version stored on the consumer, the server may return many errors during replication because the schema on the consumer cannot support the new data.

A consumer might contain replicated data from two suppliers, each with different schema. Whichever supplier was updated last wins, and its schema is propagated to the consumer.

WARNING

Never update the schema on a consumer server, because the supplier server is unable to resolve conflicts that occur, and replication fails. Schema should be maintained on a supplier server in a replicated topology.

If the standard 99user.ldif file is used for custom schema, these changes are replicated to all consumers. If there are custom schema files, ensure that these files are copied to all servers after making changes on the supplier. After all of the files have been copied, restart the server.

See Section 3.4.7, “Creating Custom Schema Files” for more information.

The same Directory Server can hold read-write replicas for which it acts as a supplier and read-only replicas for which it acts as a consumer. Therefore, always identify the server that will function 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.

NOTE

Special replication agreements are not required to replicate the schema. If replication has been configured between a supplier and a consumer, schema replication occurs by default.

Changes made to custom schema files are only replicated if the schema is updated using LDAP or the Directory Server Console. These custom schema files should be copied to each server in order to maintain the information in the same schema file on all servers. For more information, see Section 3.4.7, “Creating Custom Schema Files”.

For more information on schema design, see Chapter 3, Designing the Directory Schema.

7.4.5. Replication and Synchronization

In order to propagate synchronized Windows entries throughout the Directory Server, use synchronization within a multi-master environment. Synchronization agreement should be kept to the lowest amount possible, preferably one per deployment. Multi-master replication allows the Windows information to be available throughout the network, while limiting the data access point to a single Directory Server.