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
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
Migrating a Replicated Topology to a New Topology
Migrating Over Multiple Data Centers
8. Architectural Changes in Directory Server Since Version 5.2
9. Migrating Directory Proxy Server
Directory Server 11g Release 1 (11.1.1.5.0) supports an unlimited number of masters in a multi-master topology. This and other changes might mean that you redesign your topology rather than migrate to an identical topology with new servers. See Part III, Logical Design, in Oracle Directory Server Enterprise Edition Deployment Planning Guide before continuing.
When migrating replicated old server instances, you typically start with the consumers, continue with the hubs, and finish with the masters. This bottom-up approach involves interrupting only one server at a time, rather than interrupting an entire branch of the replication topology. The approach also helps you avoid potential custom schema synchronization issues between masters and consumers.
Note - In a Multi-Master Replication configuration that includes 5.2 servers, a maximum of four masters (of any version) is supported due to the four master restriction with version 5.2. Therefore, as long as your topology includes any 5.2 servers, the topology cannot have more than four masters.