HP-UX Directory Server Administrator Guide HP-UX Directory Server Version 8.1 (5900-3098, May 2013)

3.7.6 Replication and the attribute uniqueness plug-in
When using the Attribute Uniqueness Plug-ins on Directory Servers involved in a replication
agreement, carefully consider how to configure the plug-in on each server.
Consider the following cases:
• Simple replication with one supplier and one or several consumers.
• Complex replication with multiple masters.
Attribute Uniqueness Plug-ins do not perform any checking on attribute values when an update is
performed as part of a replication operation.
3.7.6.1 Simple replication scenario
Because all modifications by client applications are performed on the supplier server, the Attribute
Uniqueness Plug-in should be enabled on the supplier. It is unnecessary to enable it on the consumer
server.
Enabling the Attribute Uniqueness Plug-in on the consumer does not prevent Directory Server from
operating correctly but is likely to cause a performance degradation.
3.7.6.2 Multi-master replication scenario
In a multi-master replication scenario, the masters act both as suppliers and consumers of the same
replica. Because multi-master replication uses a loosely consistent replication model, enabling an
Attribute Uniqueness Plug-in on one of the servers is not sufficient to ensure that attribute values
will be unique across both supplier servers at any given time. Therefore, enabling an Attribute
Uniqueness Plug-in on one server can cause inconsistencies in the data held on each replica.
However, it is possible to use an Attribute Uniqueness Plug-in, providing both of the following
conditions are met:
• The attribute on which the uniqueness check is performed is a naming attribute.
• The Attribute Uniqueness Plug-in is enabled on both supplier servers.
When these conditions are met, attribute uniqueness conflicts are reported as naming conflicts at
replication time. Naming conflicts require manual resolution. For information on how to resolve
replication conflicts, see “Solving common replication conflicts” (page 385).
3.8 Subtree Rename and Entry Move
With previous releases, renaming operation was allowed only on leaf entries. With subtree rename
and entry move feature, the following renaming operations are allowed:
• Moving subtree to a new parent entry
• Renaming non-leaf entry
Before this feature, the backend db stores full DN as a string in the primary db file id2entry.db4.
# dn: preserves what users input
dn: ou=Accounting,dc=example,dc=com
# entrydn: normalized dn, which matches the key of
the entrydn index
entrydn: ou=accounting,dc=example,dc=com
as well as in the entrydn index file entrydn.db4:
# normalized dn: equality indexed entry id
=ou=accounting,dc=example,dc=com 2
Having these full DN strings in each entry and index key, moving a subtree or renaming a non-leaf
entry was very expensive, since every single entry and index key that are affected needs to be
modified. With the subtree rename feature, entries in the primary db file have just the RDN and a
special tree structured index file is created, called entryrdn.db4 for entry id look up.
144 Creating Directory Entries