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.

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:

• Do not modify the schema on a consumer server.

  Modifications to the schema on the consumer server can cause replication errors. This is because differences in the schema on the consumer can result in updates from the supplier not conforming to schema on the consumer.

• In a multimaster replication environment, modify schema on a single master server.

  When you modify the schema on two master servers, the master most recently updated propagates its version of the schema to the consumer. The schema on the consumer might then become inconsistent with the schema on the other master.

When configuring fractional replication, also consider the following guidelines:

• As schema is pushed by suppliers in fractional replication configurations, schema on a fractional consumer replica are a copy of the master replica’s schema. Therefore, schema might not correspond to the fractional replication configuration being applied.

• In general, Directory Server replicates all required attributes for each entry as defined in the schema to avoid schema violations. When you configure fractional replication to filter out required attributes, you must disable schema checking.

• If schema checking is enabled with fractional replication, you might not be able to initialize the replica offline. Directory Server does not allow you to load data from LDIF if required attributes are filtered out.

• If you have disabled schema checking on a fractional consumer replica, schema checking is not enforced on the whole server instance on which that fractional consumer replica resides. As a result, avoid configuring supplier replicas on the same server instance as a fractional consumer.

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.

To Limit Schema Replication

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

• 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.