Advantages of an all-master topology include the following:
■
Availability. Write trac is never disrupted if one of the servers goes down.
■
Simplicity. In an all-master topology, there is no need to set up referrals to route reads and
writes to dierent servers.
There may be reasons that an all-master topology is not viable in a specic deployment. For
example, fractional replication cannot be used in an all-master topology because fractional
replication is only supported from masters to consumers.
Migration Scenarios
This section provides sample migration scenarios for a variety of replicated topologies.
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 1.
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 rst diagram shows the version 5 topology before the migration.
MigrationScenarios
SunJavaSystemDirectoryServerEnterpriseEdition6.0 MigrationGuide • March200754
SunCondential:Registered