|
| |
| Sun Java(TM) System Directory Server 5.2 2005Q1 Installation and Migration Guide | |
Chapter 4
Migrating a Replicated 4.x TopologyWhen upgrading replicated 4.x servers, start by replicating to a new master, and then proceed branch by branch through the replication topology. This approach limits the volume of server synchronization traffic.
Note
Refer to the Directory Server Administration Guide for detailed instructions concerning replication configuration and initialization.
This chapter includes the following sections:
Preparing the New MasterDuring the upgrade, the 5.2 server is configured as a master but functions as a legacy consumer in the 4.x topology. After the upgrade, the 4.x consumer capability is disabled, and the new server functions as a master in the 5.2 topology.
This procedure calls for manual configuration of the new master server. You may therefore install the new master on a different host than the existing master.
- Follow the links in Chapter 1, "Finding Installation and Upgrade Instructions" to determine how to install the new server.
- Manually reproduce the configuration of the 4.x master on the new server.
- Make the new server a master (for the 5.2 topology).
Refer to the Directory Server Administration Guide for instructions.
- Make the new server a legacy consumer of the 4.x master (for the 4.x topology).
Again, refer to the Directory Server Administration Guide for instructions.
- Initialize replication from the 4.x master to the new server.
The process is described in "Managing Replication" in the Netscape Directory Server Administration Guide. Refer to the section entitled, "Manual Consumer Initialization."
You may now upgrade the consumers.
Upgrading the ConsumersThis procedure outlines the approach. Refer to subsequent procedures for details.
Upon completion of this procedure, the update process is complete.
Upgrading a BranchThink of the existing 4.x replication topology as a tree with the master as the root element. Here, a branch denotes a set of replicated servers in that tree for which the flow of replication originates at the root node supplier, continues out through consumers in the midst of the tree, and finally arrives at leaf node consumer servers.
Upgrading a branch consists of replacing all old servers in the branch with new servers, working from the top down.
Note
While you upgrade a server, replication flow stops to all downstream servers in the branch. Consider redirecting client requests to another branch during the upgrade.
- Proceed according to the instructions under Chapter 3, "Upgrading and Migrating Data for a Single Directory Server Installation" or follow the links in Chapter 3, "Finding Patch Update Instructions" to upgrade the top server in the branch.
This cuts replication flow to the branch, temporarily bringing replication updates on downstream servers in the branch to a halt.
- Configure the replication agreement on the new server in the 5.2 branch to receive updates from a 5.2 server closer in the replication topology to the new master.
For example, configure the top server in the new branch to receive updates from the 5.2 master.
- Initialize replication from the 5.2 supplier to the new 5.2 server.
Depending on network capacity and volume of directory data compared to updates, offline initialization may be faster than online initialization.
Refer to the Directory Server Administration Guide for instructions on configuring replication agreements and initializing replication.
At this point, the update process is complete for the branch. Repeat the procedure for the remaining 4.x branches.
Adding Additional ServersAfter completing the upgrade from the 4.x topology to the 5.2 topology, you may add additional masters, hubs, and consumers as required for the new topology.
Perform the following steps for each additional server.
- Follow the links in Chapter 1, "Finding Installation and Upgrade Instructions" to determine how to install the new server.
- Adjust replication agreements on the new server to fit the planned topology.
Refer to the Directory Server Administration Guide for instructions.
- Initialize replication on the new server.
Again, refer to the Directory Server Administration Guide for instructions.
Example 4.x Upgrade ScenarioConsider an upgrade for a 4.x master replicating to two branches, one with single consumer, one with hub supplying two consumers. This section shows the steps performed to upgrade to a new multi-master topology.
Note
In the figures that follow, solid arrows represent active replication. Dotted and dashed arrows represent interrupted replication. Dashed arrows alone represent instances being migrated.
Figure 4-1 shows the 4.x topology before upgrade.
Figure 4-1 Existing 4.x Topology Example
Figure 4-2 shows the addition of a 5.2 master that also functions as a legacy consumer of the 4.x master.
Figure 4-2 Example 4.x Topology with Additional New Server
Figure 4-3 shows the first step in replacing a 4.x branch.
Notice the entire branch stops receiving replication updates during the upgrade. This interruption starts when the upstream 4.x consumer is stopped for upgrade, and ends when you restart the 4.x consumer.
As mentioned in the instructions, you may choose to direct client requests to consumers on another branch if clients require the very latest updates available.
Figure 4-3 Example 4.x Branch During Upgrade - Step 1
Figure 4-4 shows the next step in replacing a 4.x branch.
Figure 4-4 Example 4.x Branch During Upgrade - Step 2
Figure 4-5 shows the next step in replacing a 4.x branch.
Figure 4-5 Example 4.x Branch During Upgrade - Step 3
Figure 4-6 shows replacement of the other 4.x branch.
Figure 4-6 Example 4.x Branch During Upgrade - Next Branch
Figure 4-7 shows the two topologies side by side.
Figure 4-7 Example of 4.x and 5.2 Topologies During Upgrade
Figure 4-8 shows the addition of a master, a hub and additional replication agreements to the new topology.
Figure 4-8 Adding Servers to the 5.2 Topology
You may also add additional servers after completing the upgrade process.
Figure 4-9 shows removal of the replication agreement from the old 4.x master to the new 5.2 master.
Figure 4-9 Removing the Replication Agreement
After redirecting client requests and removing the replication agreement, you may disable the 4.x servers. Figure 4-10 shows the resulting 5.2 topology.
Figure 4-10 Resulting 5.2 Topology
Client requests are now directed to the 5.2 topology.
