Replication
Overview
Replication is the
mechanism by which directory data is automatically copied from one
Directory Server to another. Updates of any kind -- entry additions,
modifications, or even deletions -- are automatically mirrored to other
Directory Servers using replication. This section contains information
on the following replication concepts:
Read-Write
Replica/Read-Only Replica
A database that
participates in replication is defined as a
replica. There are two kinds of replicas: read-write
or read-only. A read-write
replica contains master copies of directory information and can be
updated. A read-only
replica refers all update operations to read-write replicas. A
server can hold any number of read-only or read-write replicas.
Supplier/Consumer
A server that holds a
replica that is copied to a replica on a different server is called
a supplier
for that replica. A server that holds a
replica that is copied from a different server is called a consumer
for that replica. Generally, the replica
on the supplier server is a read-write replica and the one on the
consumer server is a read-only replica. There are exceptions to this
statement:
- In the case of
cascading replication,
the hub supplier holds a read-only
replica that it supplies to consumers. For more information, refer to Cascading Replication.
- In the case of
multi-master replication,
the masters are suppliers and consumers for the same read-write
replica. For more information, refer to Multi-Master Replication.
In Directory Server, replication is always
initiated by the supplier server, never by the consumer. This operation
is called supplier-initiated replication. It allows you to
configure a supplier server to push data to one or more consumer
servers.
Earlier versions of the Directory Server
allowed consumer-initiated replication, where you could
configure consumer servers to pull data from a supplier server.
Change Log
Every supplier server
maintains a change log. A change
log is a record that describes the modifications that have occurred on
a replica. The supplier server then replays these modifications to the
replicas stored on consumer servers or to other suppliers, in the case
of multi-master replication.
When an entry is modified, a change record
describing the LDAP operation that was performed is recorded in the
change log.
In Directory Server, the format of the
change log has changed. It is now only intended for internal use by the
server. If you have applications that need to read the change log, you
need to use the Retro Change Log Plug-in for backward compatibility.
For more information, refer to Using the Retro Change Log Plug-in.
Unit of Replication
The smallest unit of
replication is a database. This means
that you can replicate an entire database but not a subtree within a
database. Therefore, when you create your directory tree, you must take
your replication plans into consideration. For more information on how
to set up your directory tree, refer to the Netscape Directory
Server Deployment Guide.
The replication mechanism also requires
that one database correspond to one suffix. This means that you cannot
replicate a suffix (or namespace) that is distributed over two or more
databases using custom distribution logic. For more information on this
topic, refer to Creating
and Maintaining Databases.
Replication
Identity
When replication occurs between two servers, the
replication process uses a special entry, often referred to as the
Replication Manager entry, to identify replication protocol
exchanges. The Replication Manager entry, or any entry you create to
fulfill that role, must meet the following criteria:
- It is created on
the consumer server
(or hub supplier) and
not on the supplier server.
- You must create
this entry on
every server that receives updates from another server, meaning on
every hub supplier or dedicated consumer.
- When you configure
a replica that
receives updates from another server, you must specify this entry as
the one authorized to perform replication updates.
- When you configure
the replication
agreement on the supplier server, you must specify the DN of this entry
in the replication agreement.
- This entry must not
be part of the
replicated database for security reasons.
- This entry, with
its special user
profile, bypasses all access control rules defined on the consumer
server.
|
|
Note
|
In the Directory
Server Console, this Replication Manager entry is referred to as the
supplier bind DN , which may be
misleading as the
entry
does not actually exist on the supplier server. It is called the
supplier bind DN because it is the entry which must be present on the
consumer for the supplier to be able to bind to the consumer.
|
|
Replication
Agreement
Directory Servers use replication agreements to define their
replication configuration. A replication agreement describes replication between
one supplier and
one consumer only. The agreement is configured on the supplier
server. It specifies:
- The database to be
replicated.
- The consumer server
to which the data
is pushed.
- The times during
which replication can
occur.
- The DN and
credentials that the
supplier server must use to bind (called the Replication Manager entry
or supplier bind DN).
- How the connection
is secured (SSL,
client authentication).
Compatibility
with Earlier Versions of Directory Server
The replication mechanism in current versions of
Directory Server is different from the mechanism used in earlier
versions (4.x) of Directory Server. Compatibility is provided through
the following:
- Legacy Replication
Plug-in -- The Legacy Replication Plug-in
makes Directory
Server behave as a 4.x Directory Server in a consumer role. For
information on how to implement legacy replication using this plug-in,
refer to Replication with
Earlier Releases.
- Retro Change Log
Plug-in -- The Retro Change Log Plug-in
can be used when
you want a Directory Server supplier to maintain a 4.x style change
log. This is sometimes necessary for applications, such as Netscape
Meta Directory, that have a dependency on the Directory Server 4.x
change log format because they read information from the change log.
For more information on the Retro Change Log Plug-in, refer to Using the Retro Change Log
Plug-in.
Replication
Scenarios
This section describes
the most commonly used replication scenarios:
You can combine these basic scenarios to
build the replication environment that best suits your needs.
|
|
Note
|
Whatever
replication scenario you choose to implement, remember to consider
schema replication. For details, see Netscape Directory
Server Deployment Guide.
To avoid
conflict resolution loops,
the Referential
Integrity Plug-in should only be enabled on one supplier replica in a
multi-master replication environment. The plug-in is off by
default.
|
|
Single-Master
Replication
In the simplest replication scenario, the
master copy of directory data is held in a single read-write replica on
one server called the supplier server. The supplier server also
maintains change log for this replica. On another server, called the
consumer server, you have as many read-only replicas as you like. Such
scenarios are called single-master configurations. Figure 8-1 shows an example
of single-master replication.
Figure 8-1
Single-Master Replication
In this particular configuration, the
ou=people,
dc=example,dc=com suffix receives a large number of search
requests. Therefore, to distribute the load, this tree, which is
mastered on server A, is replicated to two read-only replicas located
on server B and server C.
For information on setting up a
single-master replication environment, refer to Configuring Single-Master
Replication.
Multi-Master
Replication
Directory Server also supports complex replication scenarios in
which the same suffix (database) can be mastered on many servers. This
suffix is held in a read-write replica on each server. This means that
each server maintains a change log for the read-write replica.
This type of configuration can work with
any number of consumer servers. Each consumer server holds a read-only
replica. The consumers can receive updates from all the suppliers. The
consumers also have referrals defined for all the suppliers to forward
any update requests that the consumers receive. Such scenarios are
called multi-master configurations.
Figure
8-2 shows an example of multi-master replication scenario with two
supplier servers and two consumer servers.
Figure 8-2
Multi-Master Replication (Two Suppliers)
Figure
8-3 shows a sample of multi-master replication scenario with four
supplier servers and eight consumer servers. In this sample setup, each
supplier server is configured with ten replication agreements to feed
data to two other supplier servers and all eight consumer servers.
Figure 8-3
Multi-Master Replication (Four Suppliers)
Multi-master configurations have the
following advantages:
- Automatic write
failover when one
supplier is inaccessible.
- Updates are made on
a local supplier in
a geographically distributed environment.
|
|
Note
|
Replication,
especially multi-master
replication, works better over high speed links than over slow links,
such as a WAN, in geographically distributed environments.
|
|
Cascading
Replication
In a cascading replication scenario, one server,
often called a hub supplier,
acts both as a consumer and a supplier
for a particular replica. It holds a read-only replica and maintains a
change log. It receives updates from the supplier server that holds the
master copy of the data and, in turn, supplies those updates to the
consumer. Cascading replication is very useful when you need to balance
heavy traffic loads or have supplier servers based locally in
geographically distributed environments.
Figure
8-4 shows an example of cascading replication. This example shows a
simple cascading replication scenario. You can create more complex
scenarios with several hub suppliers.
Figure 8-4
Cascading Replication
For information on setting up cascading
replication, refer to Configuring
Cascading Replication.
|
|
Note
|
You can combine
multi-master and cascading replication. For example, in the
multi-master scenario illustrated in Figure 8-2, server C and server D could be hub
suppliers that would replicate to any number of consumer servers.
|
|
Handling
Complex Replication Configurations
If you are configuring replication for a
large number of servers and your configuration is relatively complex,
for reasons of efficiency, you should proceed in the following order:
- On all consumer
servers:
- Create the replica databases.
- Create the Replication Manager,
or supplier bind DN, entry.
- Specify the replica settings for
a read-only replica.
- On all hub
suppliers:
- Create the replica databases.
- Create the Replication Manager,
or supplier bind DN, entry.
- Specify the supplier settings for
replication (includes change log configuration).
- Specify the replica settings for
a read-only replica.
- On all suppliers:
- Create the replica databases.
- Specify the supplier settings for
replication (includes change log configuration).
- Specify the replica settings for
a read-write replica.
- Configure
replication agreements on all
suppliers:
- Between suppliers in a
multi-master set.
- Between suppliers and dedicated
consumers.
- Between suppliers and hub
suppliers.
Optionally, you can initialize the
replicas on the consumer servers at this stage.
- Configure replication
agreements on all hub suppliers between the hub supplier and the
dedicated consumers.
Optionally, you can initialize the
replicas on the consumer servers at this stage.
|
|
Note
|
It is very
important to create and
configure all replicas before you attempt to create a replication
agreement. This also means that when you create the replication
agreement, you can choose to initialize consumers immediately.
|
|
These sections contain
a description of the
tasks you need to perform to configure replication:
Creating the
Supplier Bind DN Entry
A critical part of setting up replication is
to create the entry, referred to as the Replication Manager or supplier
bind DN entry, that the suppliers will use to bind to the consumer
servers to perform replication updates.
The supplier bind DN must meet the
following criteria:
- It must be unique.
- It must be created
on the consumer
server (or hub supplier) and
not on the supplier server.
- It must correspond
to an actual entry
on the consumer server.
- It must be created
on
every server that receives updates from another server.
- It must not be part
of the replicated
database for security reasons.
- It must be defined
in the replication
agreement on the supplier server.
For example, you could create an entry cn=Replication
Manager,cn=config under the
cn=config tree on the consumer server. This would be the
supplier bind DN that all supplier servers would use to bind to the
consumer to perform replication operations.
|
|
Note
|
Avoid creating
simple entries under the cn=config
entry in the
dse.ldif file. The cn=config
entry in the simple, flat
dse.ldif
configuration file is not stored in the same highly scalable database
as regular entries. As a result, if many entries, and particularly
entries that are likely to be updated frequently, are stored under cn=config,
performance will probably suffer.
However,
although we recommend you do
not store simple user entries under cn=config
for performance reasons, it can be useful to store special user entries
such as the Directory Manager entry or Replication Manager (supplier
bind DN) entry under cn=config, as this allows you to centralize
configuration information.
|
|
On each server that acts as a consumer in replication agreements,
create a special entry that the supplier will use to bind.
This entry must not be part of the replicated
database. For example, you could use cn=Replication
Manager,cn=config. Make sure you create the entry with the
attributes required by the authentication method you specify in the
replication agreement.
- Stop the Directory Server. If you do not stop the server, the
changes you make to the dse.ldif
file will not be saved. See Starting
and Stopping the Directory Server for more information on stopping
the server.
- Create a new entry, such as cn=replication
manager,cn=config in the dse.ldif
file.
- Specify a
userPassword attribute-value pair.
- If you have enabled
the password
expiration policy or intend to do so in the future, you must remember
to disable it to prevent replication from failing due to passwords
expiring. To disable the password expiration policy on the
userPassword attribute, add the passwordExpirationTime
attribute with a value of
20380119031407Z, which means that the password will never expire.
- The final entry should resemble this example:
dn:
cn=replication manager,cn=config
objectClass:
inetorgperson
objectClass:
person
objectClass:
top
cn:
replication manager
sn: RM
userPassword:
password
passwordExpirationTime:
20380119031407Z
- Restart the Directory
Server. See Starting
and Stopping the Directory Server for more information on starting
the server.
When you configure a replica as a consumer,
you must use the DN of this entry to define the supplier bind DN.
Configuring
Supplier Settings
On any server that holds the master copy of a
replica, you must specify supplier settings.
To configure supplier settings:
- In the Directory Server Console,
select the Configuration tab.
For information on starting the
Directory Server Console, see Using
the Directory Server Console.
- In the left navigation
tree, highlight the Replication node.
- In the right pane,
select the Supplier
Settings tab.
- Check the Enable
Change Log checkbox.
This activates all of the fields in the
pane below that were previously grayed out.
- Specify a change log
by clicking the "Use default" button, or click Browse to display a file
selector.
- Set the change log
number and age
parameters.
You must clear the unlimited checkboxes
to specify different values.
- Click Save to save the
supplier settings.
Configuring a
Read-Write Replica
For each read-write replica on the supplier server,
you must specify the appropriate replication settings.
To configure a read-write replica:
- In the Directory Server Console,
select the Configuration tab.
For information on starting the
Directory Server Console, see Using
the Directory Server Console.
- In the left navigation
tree, expand the Replication folder, and highlight the database to
replicate.
The Replication tab is displayed on the
right pane.
- Check the Enable
Replica checkbox.
- In the Replica Role
section, select the
Single Master or Multi-Master radio button.
- In the Common
Settings section, specify
a Replica ID (an integer between 1 and 254, both inclusive).
The replica
ID must be unique for a given suffix. Make sure you specify an ID that
is different from the IDs used for read-write replicas on this server
and on other servers.
- In the Common Settings
section, specify a purge delay in the "Purge delay" field.
This option indicates how often the
state information stored in the replicated entries is purged.
- Click Save to save the
replication settings for the database.
Configuring a
Read-Only Replica
For each read-only replica on the consumer server,
you must specify the appropriate replication settings.
- In the Directory Server Console,
click the Configuration tab.
For information on starting the
Directory Server Console, see Using
the Directory Server Console.
- In the left navigation
tree, expand the Replication folder, and then highlight the replica
database.
The Replica Settings tab is displayed
on the right pane.
- Check the Enable
Replica checkbox.
- In the Replica Role
section, select the
Dedicated Consumer option.
- In the Common
Settings section, specify
a purge delay in the "Purge delay" field.
This option indicates how often the
state information stored in the replicated entries is purged.
- In the Update Settings
section, specify the supplier bind DN that the supplier will use to
bind to the replica.
This supplier bind DN or entry DN must
correspond to the entry you created on the server that acts as a
consumer in the replication agreement. You can now specify multiple
supplier bind DNs per replica but only one supplier DN per replication
agreement. To specify your supplier bind DN, enter your supplier bind
DN in the "Enter a new Supplier DN" field and click Add. Your supplier
bind DN will appear in the Current Supplier DNs list. Repeat the
operation for every supplier bind DN you want to include in the list.
The supplier bind DN corresponds to a
privileged user because it is not subject to access control.
- Specify any supplier
servers to which you want to refer updates.
By default, all updates are first
referred to the supplier servers that you specify here. If you specify
none, updates are referred to the supplier servers that have a
replication agreement that includes the current replica.
Automatic referrals assume that clients
will bind over a regular connection, and, therefore, are of the form ldap://hostname:port. If you want clients to bind to the
supplier using SSL, you can use this field to specify a referral of the
form ldaps://hostname:
port,
where the s
in ldaps
indicates secure connections.
In the case of cascading replication,
referrals are automatically sent to the hub supplier, which in turn
refers the request to the original supplier. Therefore, you should set
a referral to the original supplier to replace the automatically
generated referral.
- Click Save to save the
replication settings for the replica.
Configuring a
Hub Supplier
In a cascading replication environment, configure
the hub supplier as follows:
- In the Directory Server Console,
select the Configuration tab.
For information on starting the
Directory Server Console, see Using
the Directory Server Console.
- In the left navigation
tree, expand the Replication folder, and then highlight the database to
replicate.
The Replica Settings tab is displayed
on the right pane.
- Check the Enable
Replica checkbox.
- In the Replica Role
section, select the
Hub radio button.
- In the Common
Settings section, specify
a purge delay in the "Purge delay" field.
This option indicates how often the
state information stored in the replicated entries is purged.
- In the Update Settings
section, specify the supplier bind DN that the supplier will use to
bind to the replica.
This bind DN should correspond to the
entry created in Step 2.
The bind DN corresponds to a privileged user because it is not subject
to access control.
- Specify any supplier
servers to which you want to refer updates.
By default, all updates are first
referred to the supplier servers that you specify here. If you specify
none, updates are referred to the supplier servers that have a
replication agreement that includes the current replica.
You can choose either to add the
supplier servers that you specify to the automatically generated list
or to use the supplier servers that you specify to replace the
automatically generated list of servers.
- Click Save to save the
replication settings for the database.
Creating a
Replication Agreement
This section explains
how to create a replication agreement. You must create a replication agreement on the supplier server
for each read-write replica that is supplied to a consumer server or a
hub supplier.
Before you can create a replication
agreement, you must have:
To create a replication agreement:
- In the Directory Server Console,
select the Configuration tab.
For information on starting the
Directory Server Console, see Using
the Directory Server Console.
- In the navigation
tree, expand the Replication folder, right-click the database to
replicate, and select New Replication Agreement.
Or highlight the database, and select
New Replication Agreement from the Object menu. This will start the
Replication Agreement Wizard.
- Go through the steps
in the Replication Agreement Wizard by clicking Next to move to the
following step.
When you have finished, an icon
representing the replication agreement is displayed under the database
icon. This replication agreement icon indicates that your replication
agreement is set up.
|
|
Note
|
Once you create
a replication agreement,
you cannot change the connection type (SSL or nonSSL) defined in the
agreement; this is because LDAP and LDAPS connections use different
ports. To change the connection type, you should re-create the
replication agreement.
If you have
enabled attribute encryption, you must
use a secure
connection in order for those attributes to be replicated.
|
|
Configuring
Single-Master Replication
This section provides information on configuring
single-master replication. The steps described in this section provide
a high level overview of the procedure you need to follow.
Cross-references to the detailed task descriptions are provided at each
step.
To set up single-master replication such as
the configuration shown in Figure
8-1 between supplier server A, which holds a read-write replica,
and the two consumers server B and server C, which each hold a
read-only replica, you need to perform the following procedures:
Configuring
the Read-Only Replica on the Consumer Server
- Create the
database for the read-only replica if it does not exist.
For instructions, refer to Creating Suffixes.
- Create
the entry
corresponding to the supplier bind DN on the consumer server if it does
not exist. This is the special entry that the supplier will use to bind
to the consumer.
- In the Directory Server Console,
select the Directory tab, and create an entry. For example, you could
use
cn=Replication Manager,cn=config.
- Specify
a
userPassword attribute-value pair.
- If you have enabled the password
expiration policy or intend to do so in future, you must remember to
disable it to prevent replication from failing due to passwords
expiring.
To disable the password expiration
policy on the userPassword
attribute, add the passwordExpirationTime
attribute with a value of
20380119031407Z,which means that the password will never expire.
.
|
|
Note
|
This entry
must not be part of the replicated database.
|
|
- Specify
the
replication settings required for a read-only replica.
- In the Directory Server Console,
select the Configuration tab.
- In the navigation tree, expand
the Replication folder, and highlight the replica database.
The Replica Settings tab is
displayed in the right-hand side of the window.
- Check the Enable Replica checkbox.
- In the Replica Role section,
select the Dedicated Consumer radio button.
- In the Common Settings section,
specify a purge delay in the "Purge delay" field.
This option indicates how often the
state information stored in the replicated entries is purged.
- In the Update Settings section,
specify the bind DN that the supplier will use to bind to the replica.
This supplier bind DN should
correspond to the entry created in Step 2. The supplier bind DN corresponds to a
privileged user because it is not subject to access control.
You can now specify multiple
supplier bind DNs per replica but only one supplier DN per replication
agreement. To specify your supplier bind DN, enter your supplier bind
DN in the "Enter a new Supplier DN" field, and click Add. You supplier
bind DN will appear in the Current Supplier DNs list. Repeat the
operation for every supplier bind DN you want to include in the list.
- Specify any supplier servers to
which you want to refer updates.
By default, all updates are first
referred to the supplier servers that you specify here. If you specify
none, updates are referred to the supplier servers that have a
replication agreement that includes the current replica.
Automatic referrals assume that
clients will bind over a regular connection and, therefore, are of the
form ldap://hostname:
port. If you want clients to
bind to the supplier using SSL, you can use this field to specify a
referral of the form ldaps://hostname:
port, where the s in ldaps
indicates secure connections.
- Click Save to save the
replication settings for the replica.
- Repeat these steps
for every read-only
replica in your replication configuration.
Configuring
the Read-Write Replica on the Supplier Server
- Specify the supplier
settings for the server.
- In the Directory Server Console,
select the Configuration tab.
- In the navigation tree, highlight
the Replication node.
- In the right-hand side of the
window, select the Supplier Settings tab.
- Check the Enable Change Log
checkbox.
This activates all of the fields in
the pane below that were previously greyed out.
- Specify a change log by clicking
the "Use default" button, or click the Browse button to display a file
selector.
- Set the change log parameters
(number and age).
You must clear the unlimited
checkboxes if you want to specify different values.
- Click Save to save the supplier
settings.
- Specify the
replication settings
required for a read-write replica.
- In the navigation tree on the
Configuration tab, expand the Replication node, and highlight the
database to replicate.
The Replica Settings tab is
displayed in the right-hand side of the window.
- Check the Enable Replica checkbox.
- In the Replica Role section,
select the Single Master radio button.
- In the Common Settings section,
specify a Replica ID (an integer between 1 and 254
inclusive).
The replica ID must be unique for a
given suffix, different from the IDs used for read-write replicas on
this server and on other servers.
- In the Common Settings section,
specify a purge delay in the "Purge delay" field.
This option indicates how often the
state information stored in the replicated entries is purged.
- Click Save to save the
replication settings for the database.
- Create a replication
agreement.
You must create one replication
agreement for each read-only replica. For example, in the case
illustrated in Figure 8-1,
server A holds two replication agreements, one for server B and one for
server C.
- In the navigation tree of the
Configuration tab, right-click the database to replicate, and select
New Replication Agreement.
Or highlight the database, and
select New Replication Agreement from the Object menu. This will start
the Replication Agreement Wizard.
- Go through the steps in the
replication wizard by clicking Next to move to the following step.
- When you have finished, the
replication agreement is set up.
Initializing
the Replicas for Single-Master Replication
You can initialize the
read-only replicas from the Replication Agreement Wizard or at anytime
afterwards. For information on initializing read-only replicas, refer
to Initializing Consumers.
When you have finished, the replication
agreement is set up.
Configuring
Multi-Master Replication
This section provides
information on configuring multi-master replication. In a multi-master
configuration, many suppliers can accept updates, synchronize with each
other, and update all consumers. The consumers can send referrals for
updates to all masters. The steps described in this section provide a
high-level overview of the procedures you need to follow for two sample
multi-master replication scenarios.
Configuring
2-Way Multi-Master Replication
To set up multi-master
replication such as the configuration shown in Figure 8-2, between two
suppliers server A and server B, which each hold a read-write replica,
and two consumers server C and server D, which each hold a read-only
replica, you need to perform the following procedures:
Configuring the
Read-Only Replicas on the Consumer Servers
Perform these steps on
each consumer server, server C and server D:
- Create the database for the read-only
replica, if it does not exist.
For instructions, refer to Creating Suffixes.
- Create
the entry
corresponding to the supplier bind DN if it does not exist.
|
|
Note
|
This is the
special entry that the supplier will use to bind. The entry must not be
part of the replicated database.
|
|
- In the Directory Server Console,
select the Directory tab.
- Create an entry.
For example you could use cn=Replication
Manager,cn=config.
- Specify a
userPassword attribute-value pair.
- If you have enabled the password
expiration policy or intend to do so in the future, disable it for this
entry to prevent replication from failing due to expiration of
passwords.
To disable the password expiration
policy on the userPassword
attribute, add the passwordExpirationTime
attribute with a value of
20380119031407Z, which means that the password will never expire.
- Specify the
replication settings
required for a read-only replica.
- In the Directory Server Console,
select the Configuration tab.
- In the navigation tree, expand
the Replication folder, and then select the replica database.
The Replica Settings tab is
displayed on the right pane.
- Check the Enable Replica checkbox.
- In the Replica Role section,
select the Dedicated Consumer radio button.
- In the Common Settings section,
specify a purge delay in the "Purge delay" field.
This option indicates how often the
state information stored in the replicated entries is purged.
- In the Update Settings section,
specify the bind DN or entry DN that the supplier will use to bind to
the replica.
This supplier bind DN should
correspond to the entry created in Step 2. The supplier bind DN corresponds to a
privileged user because it is not subject to access control.
You can specify multiple supplier
bind DNs per replica but only one supplier DN per replication
agreement. To specify your supplier bind DN, enter your supplier bind
DN in the "Enter a new Supplier DN" field, and click Add. You supplier
bind DN will appear in the Current Supplier DNs list. Repeat the
operation for every supplier bind DN you want to include in the list.
- Specify any supplier servers to
which you want to refer updates.
By default, all updates are first
referred to the supplier servers that you specify here. If you specify
none, updates are referred to the supplier servers that have a
replication agreement that includes the current replica.
Automatic referrals assume that
clients will bind over a regular connection and, therefore, are of the
form ldap://hostname:
port. If you want clients to
bind to the supplier using SSL, you can use this field to specify a
referral of the form ldaps://hostname:
port, where the s in ldaps
indicates secure connections.
- Click Save to save the
replication settings for the replica.
- Repeat these steps
for every read-only
replica in your replication configuration.
Configuring the
Read-Write Replicas on the Supplier Servers
Perform these steps on
each supplier server, server A and server B:
- Specify the supplier
settings for each server.
- In the Directory Server Console,
select the Configuration tab.
- In the navigation tree, highlight
the Replication node.
- In the right-hand side of the
window, select the Supplier Settings tab.
- Check the Enable Change Log
checkbox.
This activates all of the fields in
the pane below.
- Specify a change log by clicking
the "Use default" button, or click the Browse button to display a file
selector.
- Set the change log parameters
(number and age).
You must clear the unlimited
checkboxes if you want to specify different values.
- Click Save to save the supplier
settings.
- Create
the entry
corresponding to the supplier bind DN if it does not exist.
For multi-master replication, it is
necessary to create this supplier bind DN on the supplier servers (as
well as the consumers) because they act as both consumer and supplier
to the other supplier servers.
|
|
Note
|
This is the
special entry that the supplier will use to bind. The entry must not be
part of the replicated database.
|
|
- In the Directory Server Console,
select the Directory tab.
- Create an entry.
For example, you could use cn=Replication
Manager,cn=config.
- Specify a userPassword
attribute-value pair.
- If you have enabled the password
expiration policy or intend to do so in the future, disable it to
prevent replication from failing due to expiration of passwords.
To disable the password expiration
policy on the userPassword
attribute, add the passwordExpirationTime
attribute with a value of 20380119031407Z,
which means that the password will never expire.
- On server A and
server B, specify the
replication settings for the multi-mastered read-write replica.
- In the Directory Server Console,
select the Configuration tab.
- Expand the Replication node, and
select the database to replicate.
The Replica Settings tab is
displayed on the right pane.
- Check the Enable Replica checkbox.
- In the Replica Role section,
select the Multiple Master radio button.
- In the Common Settings section,
specify a Replica ID.
The replica ID must be an integer
between 1
and 254,
both inclusive, and must be unique for a given suffix. Make sure you
specify an ID that is different from the IDs used for read-write
replicas on this server and on other servers.
- In the Common Settings section,
specify a purge delay in the "Purge delay" field.
This option indicates how often the
state information stored in the replicated entries is purged.
- In the Update Settings section,
specify the supplier bind DN or entry DN that the supplier will use to
bind to the replica.
This supplier bind DN should
correspond to the entry created in Step 2. The supplier bind DN corresponds to a
privileged user because it is not subject to access control.
- Specify the supplier server to
which you want to refer updates (the other supplier in the multi-master
set).
Only specify the URL for the
supplier server if you want clients to bind using SSL. In such a case,
you must specify a URL beginning with
ldaps://.
- Click Save to save the
replication settings for the database.
- On
server A, set up
the following replication agreements:
- One with supplier server B, where
server B is configured as a
consumer for the replica.
- One for each consumer servers,
server C and server D.
To do this:
- In the Directory Server Console,
select the Configuration tab.
- In the navigation tree,
right-click the database to replicate, and select New Replication
Agreement.
Or highlight the database, and
select New Replication Agreement from the Object menu. This will start
the Replication Agreement Wizard.
- Go through the steps in the
replication wizard by clicking Next to move to the following step.
You can initialize the read-only
replicas and the read-write replica on server B from the Replication
Agreement Wizard or at anytime afterwards. For information on the order
and procedure for initializing read-only replicas, refer to Initializing the Replicas for
Multi-Master Replication and Initializing Consumers.
When you have finished, the
replication agreement is set up.
- On server B, set up
the following
replication agreements:
- One with supplier server A, where
server A is declared as a
consumer for the replica. During this operation, do not initialize
server A from server B if you have already initialized server B from
server A in Step 4.
- One for each consumer servers,
server C and server D.
|
|
Note
|
Once you
have completed these procedures,
server A and server B have mutual replication agreements, which means
that they can accept updates from each other.
|
|
When you have
configured the servers holding the read-write replicas, the necessary
replication agreements, and the servers holding the read-only replicas,
you are ready to initialize replication. You can perform this task when
you create the replication agreements on the supplier servers or at any
time afterwards.
Initializing the
Replicas for Multi-Master Replication
In the case of multi-master replication, you
should initialize replicas in the following order:
- Ensure one supplier has the complete
set of data to replicate. Use this supplier to initialize the replicas
on the other masters in the multi-master replication set.
- Initialize the
replicas on the consumer servers from any one of the two suppliers.
For information on initializing replicas,
refer to Initializing
Consumers.
Configuring
4-Way Multi-Master Replication
Directory Server
supports 4-way multi-master replication. To set up multi-master
replication such as the configuration shown in Figure 8-3, between four
supplier servers, server M1 through server M4, that each hold a
read-write replica, and eight consumer servers, server C1 through
server C8, that each hold a read-only replica, you need to perform the
following procedures:
|
|
Note
|
If you have more than 10 databases running
with replication, you may see performance degradation. Also, if you
have more than 20 replication agreements on a supplier, you may see
performance degradation. If you need to support that many consumers,
you may have to introduce one or more hub replicas between your
supplier(s) and consumers. See Configuring
Cascading Replication.
|
|
Configuring the Read-Only Replicas on
the Consumer Servers
Perform these steps on
each consumer server, server C1 through server C8:
- Create the database for the read-only
replica if it does not exist.
For instructions, refer to Creating Suffixes.
- Create
the entry
corresponding to the supplier bind DN if it does not exist.
|
|
Note
|
This is the
special entry that the supplier will use to bind. The entry must not be
part of the replicated database.
|
|
- In the Directory Server Console,
select the Directory tab.
- Create an entry.
For example, you could use cn=Replication
Manager,cn=config.
- Specify a
userPassword attribute-value pair.
- If you have enabled the password
expiration policy or intend to do so in the future, disable it to
prevent replication from failing due to expiration of passwords.
To disable the password expiration
policy on the
userPassword attribute, add the passwordExpirationTime
attribute with a value of
20380119031407Z, which means that the password will never expire.
- Specify the
replication settings
required for a read-only replica.
- In the Directory Server Console,
select the Configuration tab.
- In the navigation tree, expand
the Replication folder, and select the replica database.
The Replica Settings tab is
displayed on the right pane.
- Check the Enable Replica checkbox.
- In the Replica Role section,
select the Dedicated Consumer radio button.
- In the Common Settings section,
specify a purge delay in the "Purge delay" field.
This option indicates how often the
state information stored in the replicated entries is purged.
- In the Update Settings section,
specify the bind DN that the supplier will use to bind to the replica.
This supplier bind DN should
correspond to the entry created in Step 2. The supplier bind DN corresponds to a
privileged user because it is not subject to access control.
You can specify multiple supplier
bind DNs per replica but only one supplier DN per replication
agreement. To specify your supplier bind DN, enter your supplier bind
DN in the "Enter a new Supplier DN" field, and click Add. You supplier
bind DN will appear in the Current Supplier DNs list. Repeat the
operation for every supplier bind DN you want to include in the list.
- Specify the supplier servers to
which you want to refer updates.
By default, all updates are first
referred to the supplier servers that you specify here. If you specify
none, updates are referred to the supplier servers that have a
replication agreement that includes the current replica.
Automatic referrals assume that
clients will bind over a regular connection and, therefore, are of the
form ldap://hostname:
port. If you want clients to
bind to the supplier using SSL, you can use this field to specify a
referral of the form ldaps://hostname:
port, where the s in ldaps
indicates secure connections.
- Click Save to save the
replication settings for the replica.
- Repeat these steps
for every read-only
replica in your replication configuration.
Configuring the Read-Write Replicas on
the Supplier Servers
Perform these steps on
each supplier server, server M1 through server M4:
- Specify the supplier
settings for each server.
- In the Directory Server Console,
select the Configuration tab.
- In the navigation tree, highlight
the Replication node, and, on the right pane, select the Supplier
Settings tab.
- Check the Enable Change Log
checkbox.
This activates all of the fields in
the pane below.
- Specify a change log by clicking
the Use Default button, or click the Browse button to display a file
selector.
- Set the change log parameters
(number and age).
You must clear the unlimited
checkboxes if you want to specify different values.
- Click Save to save the supplier
settings.
- Create
the entry
corresponding to the supplier bind DN if it does not already exist.
For multi-master replication, it is
necessary to create this supplier bind DN on the supplier servers (as
well as the consumers) because they act as both consumer and supplier
to the other supplier servers.
|
|
Note
|
This is the
special entry that the supplier will use to bind. The entry must not be
part of the replicated database.
|
|
- In the Directory Server Console,
select the Directory tab.
- Create an entry.
For example, you could use cn=Replication
Manager,cn=config.
- Specify a
userPassword attribute-value pair.
- If you have enabled the password
expiration policy or intend to do so in the future, disable it to
prevent replication from failing due to expiration of passwords.
To disable the password expiration
policy on the
userPassword attribute, add the passwordExpirationTime
attribute with a value of
20380119031407Z, which means that the password will never expire.
.
- Specify the
replication settings for
the multi-mastered read-write replica.
- In the navigation tree of the
Configuration tab, expand the Replication node, and then select the
database to replicate.
The Replica Settings tab is
displayed on the right pane.
- Check the Enable Replica checkbox.
- In the Replica Role section,
select the Multiple Master radio button.
- In the Common Settings section,
specify a Replica ID.
The replica ID must be an integer
between 1
and 254,
both inclusive, and must be unique for a given suffix. Make sure you
specify an ID that is different from the IDs used for read-write
replicas on this server and on other servers.
- In the Common Settings section,
specify a purge delay in the "Purge delay" field.
This option indicates how often the
state information stored in the replicated entries is purged.
- In the Update Settings section,
specify the supplier bind DN or entry DN that the supplier will use to
bind to the replica.
This supplier bind DN should
correspond to the entry created in Step 2. The supplier bind DN corresponds to a
privileged user because it is not subject to access control.
- Specify the supplier server to
which you want to refer updates (the other suppliers in the
multi-master set).
Only specify the URL for the supplier
server. If you want clients to bind using SSL, you must specify a URL
beginning with ldaps://.
- Click Save to save the
replication settings for the database.
- Set up replication
agreements on all
the supplier servers:
- On server M1, set up the
following replication agreements: one with supplier server M2, where
server M2 is configured as a
consumer for the replica; one with supplier server M4, where
server M4 is configured as a
consumer for the replica; and one for each consumer servers,
server C1 through server C8.
- On server M2, set up the
following replication agreements: one with supplier server M1, where
server M1 is declared as a
consumer for the replica; one with supplier server M3, where
server M3 is declared as a
consumer for the replica; and one for each consumer servers,
server C1 through server C8.
- On server M3, set up the
following replication agreements: one with supplier server M2, where
server M2 is declared as a
consumer for the replica; one with supplier server M4, where
server M4 is declared as a
consumer for the replica; and one for each consumer, server C1
through server C8.
- On server M4, set up the
following replication agreements: one with supplier server M3, where
server M3 is declared as a
consumer for the replica; one with supplier server M1, where
server M1 is declared as a
consumer for the replica; and one for each consumer servers,
server C1 through server C8.
To set up a replication agreement:
- In the Directory Server Console,
select the Configuration tab.
- In the navigation tree,
right-click the database to replicate, and then select New Replication
Agreement.
Or highlight the database, and
select New Replication Agreement from the Object menu. This will start
the Replication Agreement Wizard.
- Go through the steps in the
replication wizard by clicking Next to move to the following step.
When you have
finished, the replication
agreement is set up.
|
|
Note
|
Once you have
completed these procedures,
all four servers -- server M1 through server M4 -- have mutual
replication agreements, which means that they can accept updates from
each other.
|
|
When you have
configured the servers
holding the read-write replicas, the necessary replication agreements,
and the servers holding the read-only replicas, you are ready to
initialize replication. You can perform this task when you create the
replication agreements on the supplier servers or at any time
afterwards. For information on the order and procedure for initializing
read-only replicas, refer to Initializing
the Replicas for Multi-Master Replication and Initializing Consumers.
During this operation, do not try to
reinitialize the servers. For example, do not initialize server M1 from
server M2 if you have already initialized server M2 from server M1.
Initializing the
Replicas for Multi-Master Replication
In the case of multi-master replication, you
should initialize replicas in the following order:
- Ensure one supplier has the complete
set of data to replicate. Use this supplier to initialize the replica
on the other supplier in the multi-master replication set.
- Initialize the
replicas on the consumer servers from either of the four suppliers.
Preventing
Monopolization of the Consumer in Multi-Master Replication
One of the features of multi-master
replication is that a supplier acquires exclusive access to the
consumer for the replicated area. During this time, other suppliers are
locked out of direct contact with the consumer. If a supplier attempts
to acquire access while locked out, the consumer sends back a busy
response, and the supplier sleeps for several seconds before making
another attempt.
A problem can arise if the locking supplier
is under a heavy update load or has a lot of pending updates in the
change log. If the locking supplier finishes sending updates and then
has more pending changes to send, it will immediately attempt to
reacquire the consumer and will most likely succeed, since the other
suppliers usually will be sleeping. This can cause a single supplier to
monopolize a consumer for several hours or longer.
Two attributes address this issue:
- nsds5ReplicaBusyWaitTime
Amount of time in seconds a supplier
should wait after a consumer sends back a busy response before making
another attempt to acquire access. The default is 3 seconds.
- nsds5ReplicaSessionPauseTime
Amount of time in seconds a supplier
should wait between update sessions. Set this interval so that it is at
least 1 second longer than the interval specified for nsds5ReplicaBusyWaitTime.
Increase the interval as needed until you reach an acceptable
distribution of consumer access among the suppliers. The default is 0.
These two attributes may be present in the
nsds5ReplicationAgreement
object class, which is used to describe replication agreements. You can
set the attributes at any time by using
changetype:modify with the
replace operation. The change takes effect for the next update
session if one is already in progress.
|
|
Note
|
If you set
either attribute to a negative value, Directory Server sends the client
a message and an
LDAP_UNWILLING_TO_PERFORM error code.
|
|
The two attributes are
designed so that the
nsds5ReplicaSessionPauseTime interval will always be at least 1
second longer than the interval specified for
nsds5ReplicaBusyWaitTime. The longer interval gives waiting
suppliers a better chance to gain consumer access before the previous
supplier can re-access the consumer.
- If either attribute
is specified but
not both, nsds5ReplicaSessionPauseTime
is set automatically to 1 second more than
nsds5ReplicaBusyWaitTime.
- If both attributes
are specified, but nsds5ReplicaSessionPauseTime
is less than or equal to
nsds5ReplicaBusyWaitTime, nsds5ReplicaSessionPauseTime
is set automatically to 1 second more than
nsds5ReplicaBusyWaitTime.
If Directory Server has to automatically
reset the value of nsds5ReplicaSessionPauseTime,
the value is changed internally only. The change is not visible to
clients, and it not saved to the configuration file. From an external
viewpoint, the attribute value appears as originally set.
Replica busy errors are no longer logged by
default because they are usually benign. If you want to see them, turn
on the replication error log level.
Configuring
Cascading Replication
This section provides information on setting
up cascading replication. The steps described in this section provide a
high-level overview of the procedures you need to follow, and
cross-references to the detailed task descriptions are provided at each
step.
To set up cascading replication such as the
configuration shown in Figure
8-4, between the supplier on server A, which holds a read-write
replica; the consumer/supplier on hub server B, which holds a read-only
replica; and the consumer on server C, which holds a read-only replica,
you need to perform the following procedures:
Configuring
the Read-Only Replica on the Consumer Server
To configure the
read-only replica in a consumer server:
- On the consumer server, create the
database for the replica if it does not exist.
For instructions, refer to Creating Suffixes.
- On
the consumer server, create the entry corresponding to the supplier
bind DN if it does not exist. This is the special entry that the
supplier will use to bind.
- On the consumer
server, specify the
replication settings for the read-only replica.
- In the Directory Server Console,
select the Configuration tab.
- In the navigation tree, expand
the Replication folder, and highlight the replica database.
The Replica Settings tab is
displayed on the right pane.
- Check the Enable Replica checkbox.
- In the Replica Role section,
select the Dedicated Consumer radio button.
- In the Common Settings section,
specify a purge delay in the "Purge delay" field.
This option indicates how often the
state information stored in the replicated entries is purged.
- In the Update Settings section,
specify the bind DN that the supplier will use to bind to the replica.
This supplier bind DN should
correspond to the entry created in Step 2. The supplier bind DN corresponds to a
privileged user because it is not subject to access control.
You can specify multiple supplier
bind DNs per replica but only one supplier DN per replication
agreement. To specify your supplier bind DN, enter your supplier bind
DN in the "Enter a new Supplier DN" field, and click Add. You supplier
bind DN will appear in the Current Supplier DNs list. Repeat the
operation for every supplier bind DN you want to include in the list.
- Specify any supplier servers to
which you want to refer updates.
By default, all updates are first
referred to the supplier servers that you specify here. If you specify
none, updates are referred to the supplier servers that have a
replication agreement that includes the current replica.
In the case of cascading
replication, referrals are automatically sent to the hub supplier,
which in turn refers the request to the original supplier. Therefore,
you should set a referral to the original supplier to replace the
automatically generated referral.
- On the supplier
server, set up the replication agreement between this server and the
hub supplier.
- In the navigation tree of the
Configuration tab, right-click the database to replicate, and then
select New Replication Agreement.
Or highlight the database, and
select New Replication Agreement from the Object menu. This will start
the Replication Agreement Wizard.
- Go through the steps in the
replication wizard by clicking Next to move to the following step.
You can initialize the read-only
replicas from the Replication Agreement Wizard or at anytime
afterwards. For information on initializing read-only replicas, refer
to Initializing Consumers.
- On the hub supplier,
set up the replication agreement between this server and the consumer.
When you have
configured the replicas on
each server and the necessary replication agreements among servers, you
can initialize the read-only replicas on the hub supplier and on the
consumer. You can perform this task from the Replication Agreement
Wizard while you are configuring the supplier server and the hub
supplier server or at any time afterwards.
Configuring
the Read-Only Replica on the Hub Supplier
Perform these steps on
the hub supplier that receives replication updates from the supplier
and propagates them to consumers:
- Create the database for the replica
if it does not exist.
For instructions, refer to Creating Suffixes.
- Create
the entry
corresponding to the supplier bind DN if it does not exist.
|
|
Note
|
This is the
special entry that the supplier will use to bind. The entry must not be
part of the replicated database.
|
|
- In the Directory Server Console,
select the Directory tab.
- Create an entry.
For example, you could use cn=Replication
Manager,cn=config.
- Specify a
userPassword attribute-value pair.
- If you have enabled the password
expiration policy or intend to do so in the future, disable it to
prevent replication from failing due to expiration of passwords.
To disable the password expiration
policy on the
userPassword attribute, add the passwordExpirationTime
attribute with a value of
20380119031407Z, which means that the password will never expire.
.
- Specify the required
replication settings.
- In the
Directory Server Console, select the Configuration tab.
- In the
navigation tree, expand the Replication node, and then select the
database to replicate.
The Replica Settings tab is
displayed on the right pane.
- Check the
Enable Replica checkbox.
- In the
Replica Role section, select the Hub radio button.
- In the
Common Settings section, specify a purge delay in the "Purge delay"
field.
This option indicates how often the
state information stored in the replicated entries is purged.
- In the
Update Settings section, specify the supplier bind DN that the supplier
will use to bind to the replica.
This supplier bind DN should
correspond to the entry created in Step 2. The supplier bind DN corresponds to a
privileged user because it is not subject to access control.
You can specify multiple supplier
bind DNs per replica but only one supplier DN per replication
agreement. To specify your supplier bind DN, enter your supplier bind
DN in the "Enter a new Supplier DN" field, and click Add. Your supplier
bind DN will appear in the Current Supplier DNs list. Repeat the
operation for every supplier bind DN you want to include in the list.
- Specify
any supplier servers to which you want to refer updates.
By default, all updates are first
referred to the supplier servers that you specify here. If you specify
none, updates are referred to the supplier servers that have a
replication agreement that includes the current replica.
Automatic referrals assume that
clients will bind over a regular connection and, therefore, are of the
form ldap://hostname:port. If you
want clients to bind to the supplier using SSL, you can use this field
to specify a referral of the form ldaps://hostname:port, where the s in ldaps
indicates secure connections.
- Click
Save to save the replication settings for the database.
Configuring
the Read-Write Replica on the Supplier Server
Perform these steps on
the supplier server that holds the original copy of the database:
- Specify the supplier
settings for the server.
- In the Directory Server Console,
select the Configuration tab.
- In the navigation tree, highlight
the Replication node.
- On the right pane, select the
Supplier Settings tab.
- Check the Enable Change Log
checkbox.
This activates all of the fields in
the pane.
- Specify a change log by clicking
the "Use default" button, or click the Browse button to display a file
selector.
- Set the change log parameters
(number and age).
You must clear the unlimited
checkboxes if you want to specify different values.
- Click Save to save the supplier
settings.
- Specify the required
replication
settings.
- In the navigation tree of the
Configuration tab, expand the Replication node, and then highlight the
database to replicate.
The Replica Settings tab is
displayed in the right-hand side of the window.
- Check the Enable Replica checkbox.
- In the Replica Role section,
select the Single Master radio button.
- In the Common Settings section,
specify a Replica ID.
The replica ID must be an integer
between 1
and 254,
both inclusive, and must be unique for a given suffix. Make sure you
specify an ID that is different from the IDs used for read-write
replicas on this server and on other servers.
- In the Common Settings section,
specify a purge delay in the "Purge delay" field.
This option indicates how often the
state information stored in the replicated entries is purged.
- Click Save to save the
replication settings for the database.
Initializing
the Replicas for Cascading Replication
In the case of cascading replication, you should initialize
replicas in the following order:
- Use the supplier server to
initialize the replica on the hub supplier.
- From the hub supplier,
initialize the replica on the consumer.
For information on
initializing replicas,
refer to
