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.
If you are migrating a multi-master replicated topology, a situation will arise where a 6.2 master is replicating to a version 5 server. In this situation, an object class violation will occur if changes are made to the new password policy attributes on the 6.2 server, and replicated to the version 5 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 6.2 password policy schema file (00ds6pwp.ldif) must be copied to every version 5 server that will be supplied by a 6.2 master. When the password policy schema file has been copied, restart the version 5 server.
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.
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.
Before migrating a master server, verify that there are no pending changes to be replicated. You can use the insync tool to do this.
Demote the master server to a hub, as described in Promoting or Demoting Replicas in Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide.
Migrate the hub server, either using dsmig or the manual migration progress.
Promote the hub server to a master, as described in Promoting or Demoting Replicas in Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide. 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.
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
In addition, dsmig does not migrate non-default replication manager entries. If a version 5 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 Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide.
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.