Skip Navigation Links | |
Exit Print View | |
Oracle Directory Server Enterprise Edition Administration Guide 11g Release 1 (11.1.1.5.0) |
Part I Directory Server Administration
2. Directory Server Instances and Suffixes
3. Directory Server Configuration
6. Directory Server Access Control
7. Directory Server Password Policy
8. Directory Server Backup and Restore
9. Directory Server Groups, Roles, and CoS
10. Directory Server Replication
Planning Your Replication Deployment
Recommended Interface for Configuring and Managing Replication
Summary of Steps for Configuring Replication
Summary of Steps for Configuring Replication
Enabling Replication on a Dedicated Consumer
To Create a Suffix for a Consumer Replica
To Perform Advanced Consumer Configuration
To Create a Suffix for a Hub Replica
To Modify Change Log Settings on a Hub Replica
Enabling Replication on a Master Replica
To Create a Suffix for a Master Replica
To Modify Change Log Settings on a Master Replica
Configuring the Replication Manager
Using a Non-Default Replication Manager
To Set A Non-Default Replication Manager
To Change the Default Replication Manager Password
Creating and Changing Replication Agreements
To Create a Replication Agreement
To Change the Destination of a Replication Agreement
Considerations for Fractional Replication
To Configure Fractional Replication
To Configure Replication Priority
To Initialize a Replicated Suffix from a Remote (Supplier) Server
Replica Initialization From LDIF
To Initialize a Replicated Suffix From LDIF
To Export a Replicated Suffix to LDIF
Filtering an LDIF File for Fractional Replication
Initializing a Replicated Suffix by Using Binary Copy
Restrictions for Using Binary Copy With Replication
Making a Binary Copy for Initializing a Server
Incrementally Adding Many Entries to Large Replicated Suffixes
To Add Many Entries to Large Replicated Suffixes
Replication and Referential Integrity
To Configure Replication Operations for SSL
To Configure Client Authentication Based Replication for SSL
Configuring Network Parameters
Scheduling Replication Activity
To Schedule Replication Activity
Configuring Replication Compression
To Configure Replication Compression
Modifying the Replication Topology
Changing the Replication Manager
Managing Replication Agreements
Disabling a Replication Agreement
Enabling a Replication Agreement
Deleting a Replication Agreement
Promoting or Demoting Replicas
To Promote or Demote a Replica
To Disable a Replicated Suffix
Keeping Replicated Suffixes Synchronized
Moving a Master Replica to a New Machine
To Remove a Master From an Existing Replication Topology
To Add a Master to an Existing Replication Topology
Replication With Releases Prior to Directory Server 11g Release 1 (11.1.1.5.0)
Replicating Between Directory Server 11g Release 1 (11.1.1.5.0) and Directory Server 6 or 5.2
To Enable the Retro Change Log
To Configure the Retro Change Log to Record Updates for Specified Suffixes
To Configure the Retro Change Log to Record Attributes of a Deleted Entry
Access Control and the Retro Change Log
Getting Replication Status in DSCC
Getting Replication Status by Using the Command Line
Solving Common Replication Conflicts
Solving Replication Conflicts by Using DSCC
Solving Replication Conflicts by Using the Command Line
To Rename a Conflicting Entry That has a Multivalued Naming Attribute
To Rename a Conflicting Entry With a Single-Valued Naming Attribute
Solving Orphan Entry Conflicts
Solving Potential Interoperability Problems
13. Directory Server Attribute Value Uniqueness
15. Directory Server Monitoring
Part II Directory Proxy Server Administration
16. Directory Proxy Server Tools
17. Directory Proxy Server Instances
19. Directory Proxy Server Certificates
20. Directory Proxy Server Load Balancing and Client Affinity
21. Directory Proxy Server Distribution
22. Directory Proxy Server Virtualization
23. Virtual Data Transformations
24. Connections Between Directory Proxy Server and Back-End LDAP Servers
25. Connections Between Clients and Directory Proxy Server
26. Directory Proxy Server Client Authentication
27. Directory Proxy Server Logging
28. Directory Proxy Server Monitoring and Alerts
Part III Directory Service Control Center Administration
After you have created a replication agreement and after both replicas have been configured, you must initialize the consumer replicated suffix before replication can begin. During initialization, you physically copy data from the supplier replicated suffix to the consumer replicated suffix.
In addition, certain error conditions or configuration changes require you to reinitialize replicas. For example, if the data in a single master replicated suffix is restored from a backup for any reason, you need to reinitialize all of the replicas that it updates.
When reinitializing, the contents of the replicated suffix are deleted on the consumer and replaced with the contents of the suffix on the master. This ensures that the replicas are synchronized and that replication updates can resume. All of the initialization methods described in this section automatically rebuild the indexes of the consumer replica so that the consumer is ready to respond optimally to client read requests.
With multimaster replication, consumers might not need to be reinitialized if they have been updated by the other masters in the topology.
You can initialize a suffix from a remote server by using an existing replication agreement. Use this method of initializing if possible, because it is less complicated than the other methods. Use the other methods only for large quantities of data that make the import too time consuming.
You can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help.
Online initialization of a replicated suffix by using DSCC is an easy way to initialize or reinitialize a consumer. However, if you are initializing a large number of entries, this process can be time consuming. In this case, you might find offline consumer initialization with the command line more efficient.
$ dsconf init-repl-dest -h host -p port suffix-DN destination-host:destination-port\ [destination-host:destination-port]
where destination-host:destination-port is the host and port of the destination server that you are initializing from the remote server.
$ dsconf show-repl-agmt-status -h host -p port suffix-DN destination-host:destination-port
This procedure outlines the general steps to use to initialize a replicated suffix from an LDIF file.
You can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help.
Online initialization of a replicated suffix by using DSCC is an easy way to initialize or reinitialize a consumer. However, if you are initializing a large number of entries, this process can be time consuming. In this case, you might find offline consumer initialization with the command line more efficient.
You must do this before you initialize replicas.
See To Export a Replicated Suffix to LDIF.
In a multimaster replication environment, you can use the LDIF file exported from the original master to initialize both the other masters and any consumers. In a cascading replication environment, you can use the same file to initialize both the hub replicas and their consumers.
In all cases, you must start with an LDIF file that has been exported from a configured master replica. You cannot use an arbitrary LDIF file to initialize all replicas because it does not contain replication metadata.
Do one of the following:
For fast initialization on a server that is offline (stopped), use the dsadm import command.
$ dsadm import instance-path LDIF_file suffix-DN
To initialize a replica online from an LDIF file, use the dsconf import command.
$ dsconf import -h host -p port LDIF_file suffix-DN
Using dsconf import is slower than using dsadm import, but you do not need to stop your server while performing the import operation.
For more detailed information about initializing suffixes, and for examples, see Initializing a Suffix. For detailed command usage, see dsadm(1M) and dsconf(1M).
$ dsconf show-repl-agmt-status -h host -p port suffix-DN destination-host:destination-port
You can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help.
For an offline export, type:
$ dsadm export instance-path suffix-DN LDIF_file
For an online export, type:
$ dsconf export -h host -p port suffix-DN LDIF_file
The following example will export the entire dc=example,dc=com replicated suffix and replication information to the file example_replica_export.ldif:
$ dsconf export -h host2 -p 1389 dc=example,dc=com \ /local/dsInst/ldif/example_export_replica.ldif
For more information, see Backing Up to LDIF and the dsadm(1M) and dsconf(1M) man pages.
Initializing a replica with fractional replication configured is transparent when using DSCC. Only the selected attributes will be sent to the consumer during the initialization.
If you have configured fractional replication, you should filter out any unused attributes before copying the exported LDIF file to the consumer servers. Directory Server provides the fildif tool for this purpose. This tool filters the given LDIF file to keep only the attributes that are allowed by the attribute set defined in your replication agreement.
This tool reads the server’s configuration to determine the attribute set definition. To read the configuration file, the fildif tool must be run as root or as the user who owns the process and the files (specified by the nsslapd-localuser attribute). For example, the following command filters the file exported from the dc=example,dc=com suffix in the previous example:
$ fildif -i /local/ds1/ldif/example_master.ldif \ -o /local/ds1/ldif/filtered.ldif -b "cn=host2.example.com:1389, \ cn=replica,cn=\\"dc=example,dc=com\\",cn=mapping tree,cn=config" -p /local/ds1
For the location of the fildif command, see Command Locations.
The -i and -o options are the input and output files, respectively. The -b option is the DN of the replication agreement where fractional replication is defined. You can find this DN by using this command:
$ ldapsearch -h host -p port -D cn=admin,cn=Administrators,cn=config -w - \ -b "cn=config" "(&(objectclass=nsds5replicationagreement)\ (nsDS5ReplicaPort=replica-port) (nsDS5ReplicaHost=replica-host))" dn
For example:
$ ldapsearch -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - \ -b "cn=config" "(&(objectclass=nsds5replicationagreement) \ (nsDS5ReplicaPort=2090)(nsDS5ReplicaHost=host2))" dn Enter bind password: version: 1 dn: cn=host2:1389,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config
For the full command-line syntax for the fildif tool, see the fildif(1) man page.
You can then use the filtered.ldif file produced by fildif to initialize the consumer in this replication agreement. Transfer the file to the consumer server and import it as described in Importing Data From an LDIF File.
A binary copy enables you to clone an entire server by using the binary backup files from one server to restore the identical directory contents onto another server. You can use a binary copy to initialize or reinitialize any server from the binary copy of a master or hub server, or a consumer from the binary copy of another consumer server.
Note - This advanced procedure interacts with the database files of Directory Server and should only be used by experienced administrators.
Certain restrictions on this feature make it practical and time efficient only for replicas with very large database files, for example, replicas containing millions of entries.
Because a binary copy moves database files from one machine to another, the mechanism is subject to the following strict limitations:
Both machines must run the same operating system, including any service packs or patches.
Both machines must share the same processor architecture. For example, you can perform binary copy between two UltraSPARC T1 processors but not between an UltraSPARC T1 and an AMD Opteron processor.
Both machines must be either big endian or little endian.
Both machines must map memory the same way. For example, you can perform binary copy between server instances on two 64-bit systems, but not between one server instance on a 32-bit system and another on a 64-bit system.
Both machines must have the same version of Directory Server installed, including binary format (32 bits or 64 bits), service pack, and patch level.
Both servers must have the same directory tree divided into the same suffixes. The database files for all suffixes must be copied together. Individual suffixes cannot be copied.
Each suffix must have the same indexes configured on both servers, including VLV (virtual list view) indexes. The databases for the suffixes must have the same name.
Each server must have the same suffixes configured as replicas.
If fractional replication is configured, it must be configured identically on all servers.
Attribute encryption must not be used on either server.
The attribute value uniqueness plug-in must have the same configuration on both servers if enabled, and it must be re-configured on the new copy, as explained in the following procedures.
These procedures describe alternate ways of performing a binary copy: a binary copy that does not require stopping the server and a binary copy that uses the minimum amount of disk space.
This section describes how to make a binary copy for initializing a server, and how to make a binary copy that uses minimum disk space.
Use this procedure to perform a binary copy for initializing a replicated server because it uses the normal backup functionality to create a copy of the server’s database files. Performing a normal backup ensures that all database files are in a coherent state without requiring you to stop the server.
This procedure has certain limitations. The backup and restore operations create copies of the database files on the same machine, thereby doubling the amount of disk space required by those files on each machine. Additionally, the actual copy operation on these files might take a significant amount time if your directory contains gigabytes of data.
For parts of this procedure, you can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help. Other parts of the procedure can only be done using the command line.
Include agreements from suppliers to this replica. If this replica is not a dedicated consumer, include agreements from this replica to its consumers. See Creating and Changing Replication Agreements.
This procedure uses less disk space and takes less time because it does not make backup copies of the database files. However, it requires you to stop the server that is being cloned to order to ensure that the database files are in a coherent state.
For parts of this procedure, you can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help. Other parts of the procedure can only be done using the command line.
Include agreements from suppliers to this replica. If this replica is not a dedicated consumer, include agreements from this replica to its consumers. See Creating and Changing Replication Agreements.
If you are cloning a master replica in a multimaster configuration, ensure that it is fully up-to-date with all of the latest changes from the other masters before stopping it.
In the case of cascading replication, always initialize replicas in the order shown in the following procedure.
You can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help.