This section provides sample migration scenarios for a variety of replicated topologies.
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.
For each consumer in the replicated topology:
Reroute clients to another consumer in the topology.
Disable any replication agreements to the consumer you want to migrate.
Stop the consumer.
Migrate the consumer according to the instructions under Chapter 1, Overview of the Migration Process for Directory Server.
Start the consumer.
Enable the replication agreements from the hubs to that consumer.
If you have migrated the data, check that replication is in sync.
If you have not migrated the data, reinitialize the consumer.
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 topology before the migration.
The first step involves rerouting clients and disabling replication agreements, effectively isolating the consumer from the topology.
The next step involves migrating the version 5 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.
For each hub in the replicated topology:
Disable replication agreements from the masters to the hub you want to migrate.
Disable replication agreements from the hub you want to migrate to the consumers.
Stop the hub.
Migrate the hub according to the instructions under Chapter 1, Overview of the Migration Process for Directory Server.
Start the hub.
Enable the replication agreements from the masters to that hub.
Enable the replication agreements from that hub to the consumers.
If you have migrated the data, check that replication is in sync.
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.
The first migration step involves disabling replication agreements, effectively isolating the hub from the topology.
The next step involves migrating the version 5 hub.
The next step involves enabling the replication agreements to the new hub and initializing the hub if necessary.
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.
For each master in the replicated topology:
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.
Ensure that the master is no longer receiving write requests. You can do this by enabling read-only mode on the master.
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.
Disable any replication agreements to and from the master you want to migrate.
Stop the master.
Migrate the master according to the instructions under Chapter 1, Overview of the Migration Process for Directory Server.
Start the master.
Enable the replication agreements from the master to the hubs and other masters in the topology.
If you have migrated the data, check that replication is in sync.
If you have not migrated the data, reinitialize the master from another master in the topology.
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 version 5 topology before the migration of the masters.
The first step in migrating a master involves disabling replication agreements, effectively isolating the master from the topology.
The next step involves migrating the version 5 master.
The next step involves enabling the replication agreements to and from the new master and initializing the master if necessary.
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.
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 a basic version 5 topology to a new all-master topology. Migrating to an all-master topology involves migrating the consumers, hubs, and masters, then promoting the hubs to masters and the consumers to hubs, then to masters. The following sections demonstrate a sample migration of a simple multi-master topology to a new all-master topology.
The following figure shows the existing version 5 topology.
The first step is to migrate all the servers individually, as described in Migrating a Replicated Topology to an Identical Topology. The resulting topology is illustrated in the following figure.
The next step involves promoting the hubs to masters, and creating a fully-meshed topology between the masters. To promote the hubs, follow the instructions in Promoting or Demoting Replicas in Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.
The following diagram illustrates the topology when the hubs have been promoted.
The next step involves promoting the consumers to hubs, and then to masters, and creating a fully-meshed topology between the masters. To promote the consumers, follow the instructions in Promoting or Demoting Replicas in Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.
The following diagram illustrates the topology when the consumers have been promoted.
Migrating servers over multiple data centers involves migrating each server in each data center individually. Before you start migrating replicated servers, determine whether your deployment might not be better served by changing the architecture of the topology. If you want to keep your existing topology, follow the examples in Migrating a Replicated Topology to an Identical Topology for each data center. To migrate to a new topology, follow the examples in Migrating a Replicated Topology to a New Topology for each data center.