Issues Related to Migrating Replicated Servers

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 New Password Policy

If you are migrating a multi-master replicated topology, a situation will arise where a 6.0 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.0 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.0 password policy schema file (00ds6pwp.ldif) must be copied to every version 5 server that will be supplied by a 6.0 master. When the password policy schema file has been copied, restart the version 5 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.

52

Sun Java System Directory Server Enterprise Edition 6.0 Migration Guide • March 2007

Sun Confidential: Registered

Page 52
Image 52
Sun Microsystems 8190994 manual Issues Related to Migrating Replicated Servers, Issues With the New Password Policy