Issues Related to Migrating Replicated Servers

Depending on your replication topology, and on your migration strategy, certain issues might arise when you migrate replicated servers. These issues are described in the following sections.

Issues With the Password Policy

If you are migrating a multi-master replicated topology, a situation will arise where a 11g Release 1 (11.1.1) master is replicating to a old server. In this situation, an object class violation will occur if changes are made to the password policy attributes on the 11g Release 1 (11.1.1) server, and replicated to the old server. The password policy attributes are managed internally by the server but they might be updated in the event of a bind, a user password modify, or the addition of an entry with the userpassword attribute.

To avoid the object class violation, the 11g Release 1 (11.1.1) password policy schema file (00ds6pwp.ldif) must be copied to every version 5.2 server that will be supplied by a 11g Release 1 (11.1.1) master. When the password policy schema file has been copied, restart the version 5.2 server.

Migration of Replication Agreements

If possible, you should migrate replicated servers to the same host name and port number. If you must change the host name or port number of a replicated server, all replication agreements that point to that server must be updated manually to point to the new server. For example, if you migrate a consumer server from red.example.com:1389 to blue.example.com:1389, the replication agreements on all masters that point to red.example.com:1389 must be updated manually to point to blue.example.com:1389.

Replication agreements from the migrated master to consumers in the topology are managed by the dsmig migration tool. If your topology does not support automated migration, these replication agreements must also be updated manually.

Migration of Referrals

Referrals are also affected if you migrate a master replica to a new host or port. The details of each master in a topology are present in the Replica Update Vector (RUV) of all other servers in the topology. The RUV of each server is used to determine the referrals. When you change the host name or port number of a master server during migration, all referrals to that master from other servers in the topology become invalid. The easiest way to correct this is to use the following steps, in order, when performing the migration.

1. Before migrating a master server, verify that there are no pending changes to be replicated. You can use the insync tool to do this.

2. Demote the master server to a hub, as described in Promoting or Demoting Replicas in Oracle Fusion Middleware Administration Guide for Oracle Directory Server Enterprise Edition.

3. Migrate the hub server, either using dsmig or the manual migration progress.

4. Promote the hub server to a master, as described in Promoting or Demoting Replicas in Oracle Fusion Middleware Administration Guide for Oracle Directory Server Enterprise Edition. When you promote the hub, you must assign a replicaID to the new migrated master. This new replicaID must be different to the replicaID of the old server that is being migrated, and must be unique within the replicated topology.

Manual Reset of Replication Credentials

dsmig does not migrate the password of the default replication manager entry (cn=replication manager,cn=replication,cn=config). Instead, the replication manager password is deleted. Therefore, whether you are using manual or automatic migration, you must reset the replication manager password manually.

To reset the replication manager password, use the following command:

$ dsconf set-server-prop -h host -p port def-repl-manager-pwd-file:filename
$ dsconf set-repl-agmt-prop -p port_master1 replicated_suffix \
master2:port_master2 auth-pwd-file:filename

The dsmig migrate-config command returns commands that must be launched to reset replication credentials properly.

In addition, dsmig does not migrate non-default replication manager entries. If a old version replica uses an entry other than the default replication manager, and if this entry is under cn=config, you must add the default replication manager manually. Please refer to the documentation to add a non-default replication manager entry manually. For information about adding a non-default replication manager, see Using a Non-Default Replication Manager in Oracle Fusion Middleware Administration Guide for Oracle Directory Server Enterprise Edition.

Problems Related to Tombstone Purging

In some cases, after migrating a replicated topology you might experience problems related to tombstone purging. In some cases, tombstone entries are not purged when they should be. This problem can be resolved by re-indexing the objectclass attribute of the corresponding suffix.