Initializing Replicas

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.

To Initialize a Replicated Suffix from a
Remote (Supplier) Server

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.

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.

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.

Ensure that you have set up replication agreements.

You
must do this before you initialize replicas.

Export the original copy of the suffix data from a master replicated
suffix to an LDIF file.

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 meta-data.

If you are initializing a fractional replica, filter the file
to keep only the replicated attributes, then transfer that file to all of
the consumer servers.

Filtering an LDIF File for Fractional Replication

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:

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:

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.

Initializing a Replicated Suffix by Using
Binary Copy

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.

Restrictions for Using Binary Copy With
Replication

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.

Making a Binary Copy for Initializing a
Server

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.

To Make a Binary Copy For Initializing a
Server

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.

To Use Binary Copy for Initializing a Server
Using Minimum Disk Space

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.

Caution –

This procedure must not be used to reinitialize
a master that has already participated in a multimaster replication scenario.
It can only be used to reinitialize a consumer server or to initialize a new
master server. To reinitialize an existing master replica, use online initialization,
import an LDIF file, or follow the procedure in Making a Binary Copy for Initializing a Server.

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.