Skip Navigation Links | |
Exit Print View | |
Oracle Directory Server Enterprise Edition Upgrade and Migration Guide 11 g Release 1 (11.1.1.5.0) |
Part I Patching Directory Server Enterprise Edition 7 to 11g Release 1 (11.1.1.5.0)
2. Patching Directory Server Enterprise Edition 7 to Version 11g Release 1 (11.1.1.5.0)
Part II Upgrading Directory Server Enterprise Edition 6 to 11g Release 1 (11.1.1.5.0)
3. Upgrading Directory Server Enterprise Edition 6 to Version 11g Release 1 (11.1.1.5.0)
Part III Migrating Directory Server Enterprise Edition 5.2 to Version 11g Release 1 (11.1.1.5.0)
4. Overview of the Migration Process for Directory Server
5. Automated Migration Using the dsmig Command
6. Migrating Directory Server Manually
7. Migrating a Replicated Topology
Overview of Migrating Replicated Servers
Issues Related to Migrating Replicated Servers
Issues With the Password Policy
Migration of Replication Agreements
Manual Reset of Replication Credentials
Problems Related to Tombstone Purging
Migrating a Replicated Topology to an Identical Topology
8. Architectural Changes in Directory Server Since Version 5.2
9. Migrating Directory Proxy Server
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 4, 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.2 topology before the migration.
Figure 7-1 Legacy Topology
The first step involves rerouting clients and disabling replication agreements, effectively isolating the consumer from the topology.
Figure 7-2 Isolating the Consumer From the Topology
The next step involves migrating the consumer.
Figure 7-3 Migrating 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 7-4 Placing the 11g Release 1 (11.1.1.5.0) Consumer Into the Topology
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 4, 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.
Figure 7-5 Topology With Migrated Consumers
The first migration step involves disabling replication agreements, effectively isolating the hub from the topology.
Figure 7-6 Isolating the Hub From the Topology
The next step involves migrating the legacy hub.
Figure 7-7 Migrating Hub
The next step involves enabling the replication agreements to the new hub and initializing the hub if necessary.
Figure 7-8 Placing the 11g Release 1 (11.1.1.5.0) Hub Into the Topology
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 4, 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 topology before the migration of the masters.
Figure 7-9 Topology With Consumers and Hubs Migrated
The first step in migrating a master involves disabling replication agreements, effectively isolating the master from the topology.
Figure 7-10 Isolating the Master From the Topology
The next step involves migrating a master.
Figure 7-11 Migrating Master
The next step involves enabling the replication agreements to and from the new master and initializing the master if necessary.
Figure 7-12 Placing the 11g Release 1 (11.1.1.5.0) Master Into the Topology
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 legacy topology to an 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 legacy topology.
Figure 7-13 Legacy 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.
Figure 7-14 Topology With Migrated Servers
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 Oracle Directory Server Enterprise Edition Administration Guide.
The following diagram illustrates the topology when the hubs have been promoted.
Figure 7-15 Migrated Topology With Promoted Hub Replicas
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 Oracle Directory Server Enterprise Edition Administration Guide.
The following diagram illustrates the topology when the consumers have been promoted.
Figure 7-16 New Fully-Meshed All-Master Topology
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.