Sun Directory Server Enterprise Edition 7.0 Upgrade and Migration Guide

Migrating a Replicated Topology to an Identical Topology

Before you start migrating replicated servers, determine whether your deployment might not be better served by changing the architecture of the topology. This section describes how to migrate if you want to keep your existing topology. Migrating a replicated topology to an identical topology, involves migrating the consumers, then the hubs, then the masters. The following sections demonstrate a sample migration of a simple multi-master topology.

Migrating the Consumers

For each consumer in the replicated topology:

  1. Reroute clients to another consumer in the topology.

  2. Disable any replication agreements to the consumer you want to migrate.

  3. Stop the consumer.

  4. Migrate the consumer according to the instructions under Chapter 2, Overview of the Migration Process for Directory Server.

  5. Start the consumer.

  6. Enable the replication agreements from the hubs to that consumer.

  7. If you have migrated the data, check that replication is in sync.

  8. If you have not migrated the data, reinitialize the consumer.

  9. Reroute clients back to the consumer.

The following sequence of diagrams illustrate the migration of a consumer, as described above. The first diagram shows the version 5.2 topology before the migration.

Figure 5–1 Legacy Topology

Figure shows basic multi-master topology

The first step involves rerouting clients and disabling replication agreements, effectively isolating the consumer from the topology.

Figure 5–2 Isolating the Consumer From the Topology

Figure shows consumer removed from topology

The next step involves migrating the consumer.

Figure 5–3 Migrating Consumer

Figure shows migration of one consumer

The next step involves enabling the replication agreements to the new consumer, initializing the consumer if necessary, and rerouting client applications to the new consumer.

Figure 5–4 Placing the 7.0 Consumer Into the Topology

Figure shows topology with one migrated consumer

Migrating the Hubs

    For each hub in the replicated topology:

  1. Disable replication agreements from the masters to the hub you want to migrate.

  2. Disable replication agreements from the hub you want to migrate to the consumers.

  3. Stop the hub.

  4. Migrate the hub according to the instructions under Chapter 2, Overview of the Migration Process for Directory Server.

  5. Start the hub.

  6. Enable the replication agreements from the masters to that hub.

  7. Enable the replication agreements from that hub to the consumers.

  8. If you have migrated the data, check that replication is in sync.

  9. If you have not migrated the data, reinitialize the hub.

The following sequence of diagrams illustrate the migration of a hub, as described above. The first diagram shows the topology before migrating the hubs.

Figure 5–5 Topology With Migrated Consumers

Figure shows basic multi-master topology with migrated
consumers

The first migration step involves disabling replication agreements, effectively isolating the hub from the topology.

Figure 5–6 Isolating the Hub From the Topology

Figure shows hub removed from topology

The next step involves migrating the legacy hub.

Figure 5–7 Migrating Hub

Figure shows migration of one hub

The next step involves enabling the replication agreements to the new hub and initializing the hub if necessary.

Figure 5–8 Placing the 7.0 Hub Into the Topology

Figure shows topology with migrated consumers and hub

Check that the replication on the consumers is in sync with the rest of the topology before migrating another hub. A server that has just been migrated does not have a change log, and can therefore not update consumer servers that are out of sync. Allow the topology to stabilize and all servers to synchronize before migrating the next supplier server.

Migrating the Masters

    For each master in the replicated topology:

  1. If you have client applications that write to the master you want to migrate, reroute these applications to write to another master in the topology.

  2. Ensure that the master is no longer receiving write requests. You can do this by enabling read-only mode on the master.

  3. Check that replication is synchronized between the master and all its consumers.

    Migration of the change log is not supported if you are migrating manually, so the preceding two steps are mandatory in this case. Although automatic migration does migrate the change log, you should still perform the above steps to avoid the risk of losing changes.

  4. Disable any replication agreements to and from the master you want to migrate.

  5. Stop the master.

  6. Migrate the master according to the instructions under Chapter 2, Overview of the Migration Process for Directory Server.

  7. Start the master.

  8. Enable the replication agreements from the master to the hubs and other masters in the topology.

  9. If you have migrated the data, check that replication is in sync.

  10. If you have not migrated the data, reinitialize the master from another master in the topology.

  11. If you rerouted client applications (Step 2), you can now route the applications to write to the migrated master.

The following sequence of diagrams illustrate the migration of a master, as described above. The first diagram shows the topology before the migration of the masters.

Figure 5–9 Topology With Consumers and Hubs Migrated

Figure shows basic multi-master topology with 7.0 consumers
and hubs

The first step in migrating a master involves disabling replication agreements, effectively isolating the master from the topology.

Figure 5–10 Isolating the Master From the Topology

Figure shows master removed from topology

The next step involves migrating a master.

Figure 5–11 Migrating Master

Figure shows migration of one master

The next step involves enabling the replication agreements to and from the new master and initializing the master if necessary.

Figure 5–12 Placing the 7.0 Master Into the Topology

Figure shows topology with one migrated master

Check that the replication on all hubs and consumers is in sync with the rest of the topology before migrating another master. A server that has just been migrated does not have a change log, and can therefore not update servers that are out of sync. Allow the topology to stabilize and all servers to synchronize before migrating the next supplier server.