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.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.
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 Directory Server 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.
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.
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 Directory Server Console or
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.
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.