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-supplier replication with the following plug-ins:
- Attribute Uniqueness Plug-inThe 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 samemail
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 themail
attribute is not unique. - Referential Integrity Plug-inReferential integrity works with multi-supplier replication, provided that this plug-in 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 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
For the standard schema, 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.
Note
Schema replication still occurs, even if the schemas between the supplier and replica do not match.
Replicatable changes include changes to the schema made through the web console, changes made through
ldapmodify
, and changes made directly to the 99user.ldif
file. Custom schema files, and any changes made to custom schema files, are not replicated.
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.
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.
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.
For more information on schema design, see Chapter 3, Designing the Directory Schema.
Custom Schema
If the standard 99user.ldif
file is used for custom schema, these changes are replicated to all consumers.
Custom schema files must be copied to each server in order to maintain the information in the same schema file on all servers. Custom schema files, and changes to those files, are not replicated, even if they are made through the web console or
ldapmodify
.
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.
For more information on custom schema files, see Section 3.4.7, “Creating Custom Schema Files”.
7.4.5. Replication and Synchronization
In order to propagate synchronized Windows entries throughout the Directory Server, use synchronization within a multi-supplier environment. Synchronization agreement should be kept to the lowest amount possible, preferably one per deployment. Multi-supplier replication allows the Windows information to be available throughout the network, while limiting the data access point to a single Directory Server.