Migrating Sun Java Directory Server to HP-UX Directory Server White Paper

Replication Considerations

One of the core features of HPDS is replication, the origin of which dates back to the heritage shared

with SJDS. Today, the replication features provided by HPDS and SJDS continue to be very similar,

but there are some differences, as noted in sections to follow.

Migrating Replicated Instances

The process for migrating a replicated instance is basically the same as that for migrating a non-

replicated instance. The differences are in how the databases are initialized, and in the extra

configuration required to enable replication once the new database is established.

There are special considerations to make when initializing databases for replicated suffixes. When

new LDIF is imported into a replica, some extra meta-data is automatically inserted in a special entry

called the Replica Update Vector (RUV) entry. The RUV entry is used by the replication sub-system to

keep track of the version of the data. One of the elements in the RUV entry is a version identifier

composed of random numbers and characters. Note that a RUV with a new random version identifier

is inserted only if the LDIF being imported does not already have an RUV. If the LDIF originates from

another replica, and the LDIF was exported using the –r option, then it will already have a RUV, and

the RUV will not be regenerated upon import. A problem arises when an LDIF that does not contain a

RUV entry is imported into multiple replica instances. Each replica instance will insert a new RUV entry

with a different random version identifier. Then, when replication agreements are created and a

supplier replica connects to a consumer replica, the master replica will attempt to verify that its data

version identifier matches the consumer replica’s version identifier, and as these data version

identifiers will not match, the replication protocol will halt at this point.

For an HPDS replication topology, the correct data initialization process for data stored in an SJDS

replication topology is to import the data only once, from the master SJDS instance to the master

HPDS instance. Then, initialize additional HPDS consumers by using online consumer initialization or

by exporting the master’s data to initialize any other replicas. Only use data exported from SJDS to

initialize a master HPDS instance; do not use such data for initializing HPDS consumer instances.

Replication Interoperability

The underlying technology for replication used by SJDS and HPDS is the same, and while it is

possible for SJDS and HPDS to participate in the same replication topology, HP does not

recommended nor support this for production use. Several factors make replication between recent

versions of SJDS and HPDS undesirable:

− Firstly, because the replication protocol is not standardized, and the development of the two

products is not coordinated, replication between these versions has not been thoroughly tested.

− Secondly, the management utilities cannot be used to configure replication between the two

products. Instead, replication configuration must be created in LDIF form and added manually

using the ldapmodify utility. The SJDS graphical interface attempts to hide the underlying

complexities of replication configuration by making some assumptions that do not hold true for

HPDS.

− Thirdly, some features that rely on replicated data might not work correctly if the format of that

data has changed. One such example is password policy. Because HPDS and SJDS implement

different password policy specifications, replicated password policy values will not have the same

effect for both products.