Sun Directory Server Enterprise Edition 7.0 Administration Guide

Replicating Directory Schema

Whenever you configure the replication of one or more suffixes between two servers, schema definitions are automatically replicated as well. The automatic replication of schema definitions ensures that all replicas have a complete, identical schema that defines all object classes and attributes that can be replicated to the consumers. Master servers therefore also contain the master schema.

However, schema replication is not instantaneous, even when you modify schema over LDAP. Schema replication is triggered either by updates to directory data or at the start of the first replication session after the schema is modified.

To enforce the schema on all replicas, you must at least enable schema checking on all masters. As the schema is checked on the master where the LDAP operation is performed, the schema does not need to be checked when updating the consumer. To improve performance, the replication mechanism bypasses schema checking on consumer replicas.

Note –

Do not turn off schema checking on hubs and dedicated consumers. Schema checking has no performance impact on a consumer. Keep schema checking on to indicate that the replica contents conform to its schema.

Master servers replicate the schema automatically to their consumers during consumer initialization. Master servers also replicate the schema automatically any time the schema is modified through DSCC or through the command-line tools. By default, the entire schema is replicated. Any additional schema elements that do not yet exist on the consumer are created on the consumer and stored in the 99user.ldif file.

For example, assume that a master server contains schema definitions in the 98mySchema.ldif file when the server is started. Also assume that you then define replication agreements to other servers, either masters, hubs, or dedicated consumers. When you subsequently initialize the replicas from this master, the replicated schema contains the definitions from 98mySchema.ldif, but the definitions are stored in 99user.ldif on the replica servers.

After the schema has been replicated during consumer initialization, modifying the schema in cn=schema on the master also replicates the entire schema to the consumer. Therefore, any modifications to the master schema through the command-line utilities or through DSCC are replicated to the consumers. These modifications are stored in 99user.ldif on the master, and by the same mechanism as described previously, the modifications are also stored in 99user.ldif on the consumers.

Consider the following guidelines for maintaining consistent schema in a replicated environment:

When configuring fractional replication, also consider the following guidelines:

Limiting Schema Replication

By default, whenever the replication mechanism replicates the schema, it sends the entire schema to its consumers. In the following situation, it is not desirable to send the entire schema to consumers:

Modifications to cn=schema using DSCC or from the command-line are limited to the user-defined schema elements, and all of the standard schema are unchanged. If you modify the schema often, sending the large set of unchanged schema elements every time has a performance impact. You might be able to improve replication and server performance by replicating only the user-defined schema elements.

ProcedureTo Limit Schema Replication

You cannot use DSCC to perform this task. Use the command line, as described in this procedure.

  1. Limit schema replication so that only the user-defined schema is replicated.

    $ dsconf set-server-prop -h host -p port repl-user-schema-enabled:on

    The default value, off, causes the entire schema to be replicated when necessary.