OpenDJ uses advanced data replication with automated conflict resolution to help ensure your directory services remain available in the event a server crashes or a network goes down, and also as you backup or upgrade your directory service. You can configure data replication as part of OpenDJ installation, and in many cases let replication do its work in the background.
You can set up replication during installation by choosing to configure replication through the setup wizard.
In the Topology Options screen for the first server you set up, select This server will be part of a replication topology. If you also choose Configure as Secure, then replication traffic is protected by SSL.
In the Topology Options screen for subsequent servers, also select There is already a server in the topology, providing the Host Name, Administration Connector Port number, Admin User, and Admin Password for the first replica you set up.
You also set up a global administrator account, stored under
cn=admin data across replicas, used to manage replication
in the topology.
You further set up what to replicate.
Once replication is set up, it works for all the replicas. You can monitor the replication connection and status through the OpenDJ Control Panel.
Before you take replication further than setting up replication in the setup wizard, read this section to learn more about how OpenDJ replication works.
Replication is the process of copying updates between OpenDJ directory servers such that all servers converge on identical copies of directory data. Replication is designed to let convergence happen over time by default. [1] Letting convergence happen over time means that different replicas can be momentarily out of sync, but it also means that if you lose an individual server or even an entire data center, your directory service can keep on running, and then get back in sync when the servers are restarted or the network is repaired.
Replication is specific to the OpenDJ directory service. Replication uses a specific protocol that replays update operations quickly, storing enough historical information about the updates to resolve most conflicts automatically. For example, if two client applications separately update a user entry to change the phone number, replication can work out which was the latest change, and apply that change across servers. The historical information needed to resolve these issues is periodically purged to avoid growing larger and larger forever. As a directory administrator, you must ensure that you do not purge the historical information more often than you backup your directory data.
The primary unit of replication is the suffix, specified by a
base DN such as dc=example,dc=com. [2] Replication also depends on the directory schema, defined on
cn=schema, and the cn=admin data
suffix with administrative identities and certificates for protecting
communications. Thus that content gets replicated as well.
The set of replicas sharing data in a given suffix is called
a replication topology. You can have more than one replication topology.
For example, one topology could be devoted to
dc=example,dc=com, and another to
dc=example,dc=org. Directory servers are capable of
serving more than one suffix. They are also capable of participating in
more than one replication topology.
Keep server clocks synchronized for your topology. You can use NTP for example. Keeping server clocks synchronized helps prevent issues with SSL connections and with replication itself. Keeping server clocks synchronized also makes it easier to compare timestamps from multiple servers.
This section shows how to configure replication with command-line tools.
You can start the replication process by using the dsreplication enable command.
To enable secure connections for replication use the
--secureReplication1 and
--secureReplication2 options, which are equivalent to
selecting Configure as Secure in the replication topology options screen of
the setup wizard.
As you see in the command output, replication is set up to function once enabled. You must however initialize replication in order to start the process.
Tip
When scripting the configuration to set up multiple replicas in quick
succession, use the same initial replication server each time you run the
command. In other words, pass the same --host1,
--port1, --bindDN1,
--bindPassword1, and --replicationPort1
options for each of the other replicas that you set up in your
script.
If you need to add another OpenDJ directory server to participate in replication, use the dsreplication enable with the new server as the second server.
Although you can enable replication before you have user data, you must initialize each replica to activate the replication process.
You can perform initialization either over the replication protocol, by importing the same LDIF data on all server before performing initialization when starting out, by importing data from LDIF that you exported from another replica when adding a server to the topology, or by restoring a backup from an existing replica onto a new server.
Online initialization is straightforward, and works well if your network bandwidth is large compared to the amount of data to replicate.
Make sure you have enabled servers you want to participate in replication.
Start replication with the dsreplication initialize-all command.
$ dsreplication initialize-all --adminUID admin --adminPassword password --baseDN dc=example,dc=com --hostname opendj.example.com --port 4444 --trustAll --no-prompt Initializing base DN dc=example,dc=com with the contents from opendj.example.com:4444: 160 entries processed (100 % complete). Base DN initialized successfully. See /var/.../opends-replication-5020375834904394170.log for a detailed log of this operation.
Follow these steps to prepare a replication topology starting from directory data in LDIF.
Depending on the size of the data and your network bandwidth, you might find it quicker to initialize all replica as described in Procedure 8.1, “To Initialize Online”, and then import the LDIF on a single replica.
Import the same LDIF on all servers you want to participate in replication.
Make sure you have enabled servers you want to participate in replication.
Start replication with the dsreplication initialize-all command.
$ dsreplication initialize-all --adminUID admin --adminPassword password --baseDN dc=example,dc=com --hostname opendj.example.com --port 4444 --trustAll --no-prompt Initializing base DN dc=example,dc=com with the contents from opendj.example.com:4444: 161 entries processed (100 % complete). Base DN initialized successfully. See /var/.../opends-replication-5745536041520679254.log for a detailed log of this operation.
You can create a new replica from a backup of a server in the existing topology. The dsreplication commands use differ slightly from the other cases, as you must reset the generation ID on the new replica, such that replication can proceed from the proper starting point. Follow these steps to add another server to the topology.
Install a new server to serve as the new replica.
Backup the database to replicate from an existing server.
Enable replication on the new replica.
$ dsreplication enable --adminUID admin --adminPassword password --baseDN dc=example,dc=com --host1 opendj.example.com --port1 4444 --bindDN1 "cn=Directory Manager" --bindPassword1 password --replicationPort1 8989 --host2 opendj.example.com --port2 6444 --bindDN2 "cn=Directory Manager" --bindPassword2 password --replicationPort2 10989 --trustAll --no-prompt Establishing connections ..... Done. Checking registration information ..... Done. Updating remote references on server opendj.example.com:4444 ..... Done. Configuring Replication port on server opendj.example.com:6444 ..... Done. Updating replication configuration for baseDN dc=example,dc=com on server opendj.example.com:4444 ..... Done. Updating replication configuration for baseDN dc=example,dc=com on server opendj.example.com:6444 ..... Done. Updating replication configuration for baseDN dc=example,dc=com on server opendj.example.com:5444 ..... Done. Updating remote references on server opendj.example.com:5444 ..... Done. Updating registration configuration on server opendj.example.com:4444 ..... Done. Updating registration configuration on server opendj.example.com:6444 ..... Done. Updating registration configuration on server opendj.example.com:5444 ..... Done. Updating replication configuration for baseDN cn=schema on server opendj.example.com:4444 ..... Done. Updating replication configuration for baseDN cn=schema on server opendj.example.com:6444 ..... Done. Updating replication configuration for baseDN cn=schema on server opendj.example.com:5444 ..... Done. Initializing registration information on server opendj.example.com:6444 with the contents of server opendj.example.com:4444 ..... Done. Replication has been successfully enabled. Note that for replication to work you must initialize the contents of the base DN's that are being replicated (use dsreplication initialize to do so). See /var/.../opends-replication-1672058070147419978.log for a detailed log of this operation.Prepare the new replica for initialization.
$ dsreplication pre-external-initialization --adminUID admin --adminPassword password --port 6444 --baseDN dc=example,dc=com --trustAll --no-prompt Preparing base DN dc=example,dc=com to be initialized externally ..... Done. Now you can proceed to the initialization of the contents of the base DN's on all the replicated servers. You can use the command import-ldif or the binary copy to do so. You must use the same LDIF file or binary copy on each server. When the initialization is completed you must use the subcommand 'post-external-initialization' for replication to work with the new base DN's contents.On the new server, restore the database from the backup archive.
Initialize replication on the new replica.
$ dsreplication post-external-initialization --adminUID admin --adminPassword password --port 6444 --baseDN dc=example,dc=com --trustAll --no-prompt Updating replication information on base DN dc=example,dc=com ..... Done. Post initialization procedure completed successfully.
How you stop replication depends on whether the change is meant to be temporary or permanent.
If you need to stop a server from replicating temporarily, you can do so using dsconfig command.
Warning
Do not allow modifications on the replica for which replication is disabled, as no record of such changes is kept, and the changes cause replication to diverge.
Disable the multimaster synchronization provider.
$ dsconfig set-synchronization-provider-prop --port 5444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --bindPassword password --provider-name "Multimaster Synchronization" --set enabled:false --trustAll --no-promptWhen you are ready to resume replication, enable the multimaster synchronization provider.
$ dsconfig set-synchronization-provider-prop --port 5444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --bindPassword password --provider-name "Multimaster Synchronization" --set enabled:true --trustAll --no-prompt
If you need to stop a server from replicating permanently, for example in preparation to remove a server, you can do so with the dsreplication disable command.
Stop replication using the dsreplication disable command.
$ dsreplication disable --disableAll --port 5444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --adminPassword password --trustAll --no-prompt Establishing connections ..... Done. Disabling replication on base DN cn=admin data of server opendj.example.com:5444 ..... Done. Disabling replication on base DN dc=example,dc=com of server opendj.example.com:5444 ..... Done. Disabling replication on base DN cn=schema of server opendj.example.com:5444 ..... Done. Disabling replication port 9989 of server opendj.example.com:5444 ..... Done. Removing registration information ..... Done. Removing truststore information ..... Done. See /var/.../opends-replication-125248191132797765.log for a detailed log of this operation.The dsreplication disable as shown completely removes the replication configuration information from the server.
If you want to restart replication for the server, you need to run the dsreplication enable and dsreplication initialize commands again.
Replication in OpenDJ is designed to be both easy to implement in environments with a few servers, and also scalable in environments with many servers. You can enable the replication service on each OpenDJ directory server in your deployment, for example, to limit the number of servers you deploy. Yet in a large deployment, you can use stand-alone replication servers — OpenDJ servers that do nothing but relay replication messages — to configure (and troubleshoot) the replication service separately from the directory service. You only need a few stand-alone replication servers publishing changes to serve many directory servers subscribed to the changes. Furthermore, replication is designed such that you need only connect a directory server to the nearest replication server for the directory server to replicate with all others in your topology. Yet only the stand-alone replication servers participate in fully-meshed replication.
All replication servers in a topology are connected to all other replication servers. Directory servers are connected only to one replication server at a time, and their connections should be to replication servers on the same LAN. Therefore the total number of replication connections, Totalconn is expressed as follows.
Here, NRS is the number of replication servers, and NDS is the number of stand-alone directory servers. In other words, if you have only three servers, then Totalconn is three with no stand-alone servers. However, if you have two data centers, and need 12 directory servers, then with no stand-alone directory servers Totalconn is (12 * 11)/2 or 66. Yet, with four stand-alone replication servers, and 12 stand-alone directory servers, Totalconn is (4 * 3)/2 + 12, or 18, with only four of those connections needing to go over the WAN. (By running four directory servers that also run replication servers and eight stand-alone directory servers, you reduce the number of replication connections to 14 for 12 replicas.)
Tip
If you set up OpenDJ directory server to replicate by using the Quick Setup wizard, then the wizard activated the replication service for that server. You can turn off the replication service on OpenDJ directory server, and then configure the server to work with a separate, stand-alone replication server instead. Start by using the dsreplication disable --disableReplicationServer command to turn off the replication service on the server.
This example sets up a stand-alone replication server to handle the replication traffic between two directory servers that do not handle replication themselves.
Here the replication server has admin port 6444. The directory servers have admin ports 4444 and 5444.
In a real deployment, you would have more replication servers to avoid a single point of failure.
Setup the replication server as a directory server that has no database.
Setup the directory servers as stand-alone directory servers.
Enable replication with the appropriate
--noReplicationServerand--onlyReplicationServeroptions.$ dsreplication enable --adminUID admin --adminPassword password --baseDN dc=example,dc=com --host1 opendj.example.com --port1 4444 --bindDN1 "cn=Directory Manager" --bindPassword1 password --noReplicationServer1 --host2 opendj.example.com --port2 6444 --bindDN2 "cn=Directory Manager" --bindPassword2 password --replicationPort2 8989 --onlyReplicationServer2 --trustAll --no-prompt Establishing connections ..... Done. Only one replication server will be defined for the following base DN's: dc=example,dc=com It is recommended to have at least two replication servers (two changelogs) to avoid a single point of failure in the replication topology. Checking registration information ..... Done. Configuring Replication port on server opendj.example.com:6444 ..... Done. Updating replication configuration for baseDN dc=example,dc=com on server opendj.example.com:4444 ..... Done. Updating registration configuration on server opendj.example.com:4444 ..... Done. Updating registration configuration on server opendj.example.com:6444 ..... Done. Updating replication configuration for baseDN cn=schema on server opendj.example.com:4444 ..... Done. Initializing registration information on server opendj.example.com:6444 with the contents of server opendj.example.com:4444 ..... Done. Replication has been successfully enabled. Note that for replication to work you must initialize the contents of the base DN's that are being replicated (use dsreplication initialize to do so). See /var/.../opends-replication-1720959352638609971.log for a detailed log of this operation. $ dsreplication enable --adminUID admin --adminPassword password --baseDN dc=example,dc=com --host1 opendj.example.com --port1 5444 --bindDN1 "cn=Directory Manager" --bindPassword1 password --noReplicationServer1 --host2 opendj.example.com --port2 6444 --bindDN2 "cn=Directory Manager" --bindPassword2 password --replicationPort2 8989 --onlyReplicationServer2 --trustAll --no-prompt Establishing connections ..... Done. Only one replication server will be defined for the following base DN's: dc=example,dc=com It is recommended to have at least two replication servers (two changelogs) to avoid a single point of failure in the replication topology. Checking registration information ..... Done. Updating remote references on server opendj.example.com:6444 ..... Done. Updating replication configuration for baseDN dc=example,dc=com on server opendj.example.com:5444 ..... Done. Updating replication configuration for baseDN dc=example,dc=com on server opendj.example.com:4444 ..... Done. Updating registration configuration on server opendj.example.com:5444 ..... Done. Updating registration configuration on server opendj.example.com:6444 ..... Done. Updating registration configuration on server opendj.example.com:4444 ..... Done. Updating replication configuration for baseDN cn=schema on server opendj.example.com:5444 ..... Done. Updating replication configuration for baseDN cn=schema on server opendj.example.com:4444 ..... Done. Initializing registration information on server opendj.example.com:5444 with the contents of server opendj.example.com:6444 ..... Done. Replication has been successfully enabled. Note that for replication to work you must initialize the contents of the base DN's that are being replicated (use dsreplication initialize to do so). See /var/folders/.../opends-replication-5893037538856033562.log for a detailed log of this operation.Initialize replication from one of the directory servers.
$ dsreplication initialize-all --adminUID admin --adminPassword password --baseDN dc=example,dc=com --hostname opendj.example.com --port 4444 --trustAll --no-prompt Initializing base DN dc=example,dc=com with the contents from opendj.example.com:4444: 160 entries processed (100 % complete). Base DN initialized successfully. See /var/.../opends-replication-7677303986403997574.log for a detailed log of this operation.
Replication lets you define groups so that replicas communicate first with replication servers in the group before going to replication servers outside the group. Groups are identified with unique numeric group IDs.
Replication groups are designed for deployments across multiple data centers, where you aim to focus replication traffic on the LAN rather than the WAN. In multi-data center deployments, group nearby servers together.
For each group, set the appropriate group ID for the topology on both the replication servers and the directory servers.
The example commands in this procedure set up two replication groups, each with a replication server and a directory server. The directory servers have admin ports 4444 and 5444. The replication servers have admin ports 6444 and 7444. In a full-scale deployment, you would have multiple servers of each type in each group, such as all the replicas and replication servers in each data center being in the same group.
Pick a group ID for each group.
The default group ID is 1.
Set the group ID for each group by replication domain on the directory servers.
$ dsconfig set-replication-domain-prop --port 4444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --bindPassword password --provider-name "MultimasterSynchronization" --domain-name "dc=example,dc=com" --set group-id:1 --trustAll --no-prompt $ dsconfig set-replication-domain-prop --port 5444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --bindPassword password --provider-name "Multimaster Synchronization" --domain-name "dc=example,dc=com" --set group-id:2 --trustAll --no-promptSet the group ID for each group on the replication servers.
$ dsconfig set-replication-server-prop --port 6444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --bindPassword password --provider-name "Multimaster Synchronization" --set group-id:1 --trustAll --no-prompt $ dsconfig set-replication-server-prop --port 7444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --bindPassword password --provider-name "Multimaster Synchronization" --set group-id:2 --trustAll --no-prompt
By default all directory servers in a replication topology are read-write. You can however choose to make replicas take updates only from the replication protocol, and refuse updates from client applications.
In standard replication, when a client requests an update operation the directory server performs the update and, if the update is successful, sends information about the update to the replication service, and sends a result code to the client application right away. As a result, the client application can conclude that the update was successful, but only on the replica that handled the update.
Assured replication lets you force the replica performing the initial update to wait for confirmation that the update has been received elsewhere in the topology before sending a result code to the client application. You can configure assured replication either to wait for one or more replication servers to acknowledge having received the update, or to wait for all directory servers to have replayed the update.
As you might imagine, assured replication is theoretically safer than standard replication, yet it is also slower, potentially waiting for a timeout before failing when the network or other servers are down.
Safe data mode requires the update be sent to
assured-sd-level replication servers before
acknowledgement is returned to the client application.
For each directory server, set safe data mode for the replication domain, and also set the safe data level.
$ dsconfig set-replication-domain-prop --port 4444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --bindPassword password --provider-name "Multimaster Synchronization" --domain-name "dc=example,dc=com" --set assured-type:safe-data --set assured-sd-level:1 --trustAll --no-prompt $ dsconfig set-replication-domain-prop --port 5444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --bindPassword password --provider-name "Multimaster Synchronization" --domain-name "dc=example,dc=com" --set assured-type:safe-data --set assured-sd-level:1 --trustAll --no-prompt
Safe read mode requires the update be replayed on all directory servers before acknowledgement is returned to the client application.
For each directory server, set safe read mode for the replication domain.
$ dsconfig set-replication-domain-prop --port 4444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --bindPassword password --provider-name "Multimaster Synchronization" --domain-name "dc=example,dc=com" --set assured-type:safe-read --trustAll --no-prompt $ dsconfig set-replication-domain-prop --port 5444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --bindPassword password --provider-name "Multimaster Synchronization" --domain-name "dc=example,dc=com" --set assured-type:safe-read --trustAll --no-prompt
When working with assured replication, the replication server property
degraded-status-threshold (default: 5000), sets the
number of operations allowed to build up in the replication queue before
the server is assigned degraded status. When a replication server has
degraded status, assured replication ceases to have an effect.
OpenDJ can perform subtree replication, for example replicating
ou=People,dc=example,dc=com, but not the rest of
dc=example,dc=com, by putting the subtree in a separate
backend from the rest of the suffix.
For example, in this case you might have a userRoot
backend containing everything in dc=example,dc=com
except ou=People,dc=example,dc=com, and a separate
peopleRoot backend for
ou=People,dc=example,dc=com. Then you replicate
ou=People,dc=example,dc=com in its own topology.
OpenDJ can perform fractional replication, whereby you specify the attributes to include in or to exclude from the replication process.
You set fractional replication configuration as
fractional-include or
fractional-exclude properties for a replication
domain. When you include attributes, the attributes that are required on
the relevant object classes are also included, whether you specify them
or not. When you exclude attributes, the excluded attributes must be
optional attributes for the relevant object classes. Fractional
replicas still respect schema definitions.
Fractional replication works by filtering objects at the replication server. Initialize replication as you would normally. Of course you cannot create a full replica from a replica with only a subset of the data. If you must prevent data from being replicated across a national boundary, split the replication server handling the updates from the directory servers receiving the updates as described in Procedure 8.6, “To Set Up a Stand-alone Replication Server”.
For example, you might configure an externally facing
fractional replica to include only some inetOrgPerson
attributes.
As another example, you might exclude a custom attribute called
sessionToken from being replicated.
This last example only works if you first define a
sessionToken attribute in the directory server
schema.
Some applications require notification when directory data updates occur. For example, an application might need to sync directory data with another database, or the application might need to kick off other processing when certain updates occur.
In addition to supporting persistent search operations, OpenDJ provides an external change log mechanism to allow applications to be notified of changes to directory data.
OpenDJ directory servers without replication cannot expose an external change log. The OpenDJ server that exposes the change log must function both as a directory server, and also as a replication server for the suffix whose changes you want logged.
Enable replication without using the
--noReplicationServeror--onlyReplicationServeroptions.With replication enabled, the changelog data can be accessed under
cn=changelog. For example, the following search shows the publicly visible data available before any changes have been made.$ ldapsearch --baseDN cn=changelog --port 1389 "(objectclass=*)" \* + dn: cn=changelog cn: changelog objectClass: top objectClass: container subschemaSubentry: cn=schema hasSubordinates: false entryDN: cn=changelog
You read the external change log over LDAP. In addition, when you poll the change log periodically, you can get the list of updates that happened since your last request.
The external change log mechanism uses an LDAP control with
OID 1.3.6.1.4.1.26027.1.5.4 to allow the exchange
of cookies for the client application to bookmark the last changes seen,
and then start reading the next set of changes from where it left off on
the previous request.
This procedure shows the client reading the change log as
cn=Directory Manager. Make sure your client application
reads the changes with sufficient access to view all the changes it
needs to see.
Send an initial search request using the LDAP control with no cookie value.
Notice the value of the
changeLogCookieattribute for the last of the two changes.$ ldapsearch --baseDN cn=changelog --port 1389 --bindDN "cn=Directory Manager" --bindPassword password --control "1.3.6.1.4.1.26027.1.5.4:false" "(objectclass=*)" \* + dn: cn=changelog cn: changelog objectClass: top objectClass: container subschemaSubentry: cn=schema hasSubordinates: true entryDN: cn=changelog # Public changelog exchange control(1.3.6.1.4.1.26027.1.5.4): dc=example,dc=com:0000013087cbc28212d100000001; dn: replicationCSN=0000013087cbc28212d100000001,dc=example,dc=com,cn=changelog targetDN: cn=arsene lupin,ou=special users,dc=example,dc=com changeNumber: 0 changes:: b2JqZWN0Q2xhc3M6IHBlcnNvbgpvYmplY3RDbGFzczogdG9wCmNuOiBBcnNlbmUgTHVwaW 4KdGVsZXBob25lTnVtYmVyOiArMzMgMSAyMyA0NSA2NyA4OQpzbjogTHVwaW4KZW50cnlVVUlEOiA5M GM3MTRmNy00ODZiLTRkNDctOTQwOS1iNDRkMTlkZWEzMWUKY3JlYXRlVGltZXN0YW1wOiAyMDExMDYx MzA2NTg1NVoKY3JlYXRvcnNOYW1lOiBjbj1EaXJlY3RvcnkgTWFuYWdlcixjbj1Sb290IEROcyxjbj1 jb25maWcK changeType: add changeTime: 20110613065855Z objectClass: top objectClass: changeLogEntry targetEntryUUID: 90c714f7-486b-4d47-9409-b44d19dea31e replicationCSN: 0000013087cbc28212d100000001 numSubordinates: 0 replicaIdentifier: 4817 changeLogCookie: dc=example,dc=com:0000013087cbc28212d100000001; changeInitiatorsName: cn=Directory Manager,cn=Root DNs,cn=config subschemaSubentry: cn=schema hasSubordinates: false entryDN: replicationCSN=0000013087cbc28212d100000001,dc=example,dc=com,cn=change log # Public changelog exchange control(1.3.6.1.4.1.26027.1.5.4): dc=example,dc=com:0000013087cbc34a12d100000002; dn: replicationCSN=0000013087cbc34a12d100000002,dc=example,dc=com,cn=changelog targetDN: cn=horace velmont,ou=special users,dc=example,dc=com changeNumber: 0 changes:: b2JqZWN0Q2xhc3M6IHBlcnNvbgpvYmplY3RDbGFzczogdG9wCmNuOiBIb3JhY2UgVmVsbW 9udAp0ZWxlcGhvbmVOdW1iZXI6ICszMyAxIDEyIDIzIDM0IDQ1CnNuOiBWZWxtb250CmVudHJ5VVVJR DogNmIyMjQ0MGEtNzZkMC00MDMxLTk0YjctMzViMWQ4NmYwNjdlCmNyZWF0ZVRpbWVzdGFtcDogMjAx MTA2MTMwNjU4NTVaCmNyZWF0b3JzTmFtZTogY249RGlyZWN0b3J5IE1hbmFnZXIsY249Um9vdCBETnM sY249Y29uZmlnCg== changeType: add changeTime: 20110613065855Z objectClass: top objectClass: changeLogEntry targetEntryUUID: 6b22440a-76d0-4031-94b7-35b1d86f067e replicationCSN: 0000013087cbc34a12d100000002 numSubordinates: 0 replicaIdentifier: 4817 changeLogCookie: dc=example,dc=com:0000013087cbc34a12d100000002; changeInitiatorsName: cn=Directory Manager,cn=Root DNs,cn=config subschemaSubentry: cn=schema hasSubordinates: false entryDN: replicationCSN=0000013087cbc34a12d100000002,dc=example,dc=com,cn=change logIn this example, two new users were added to another replica before the change log request was made.
Here the changes are base64 encoded, so you can decode them using the base64 command.
$ base64 decode --encodedData b2JqZW...ZmlnCg== objectClass: person objectClass: top cn: Horace Velmont telephoneNumber: +33 1 12 23 34 45 sn: Velmont entryUUID: 6b22440a-76d0-4031-94b7-35b1d86f067e createTimestamp: 20110613065855Z creatorsName: cn=Directory Manager,cn=Root DNs,cn=configFor the next search, provide the cookie to start reading where you left off last time.
In this example, a description was added to Babs Jensen's entry.
$ ldapsearch --baseDN cn=changelog --port 1389 --bindDN "cn=Directory Manager" --bindPassword password --control "1.3.6.1.4.1.26027.1.5.4:false: dc=example,dc=com:0000013087cbc34a12d100000002;" "(objectclass=*)" \* + dn: cn=changelog cn: changelog objectClass: top objectClass: container subschemaSubentry: cn=schema hasSubordinates: true entryDN: cn=changelog # Public changelog exchange control(1.3.6.1.4.1.26027.1.5.4): dc=example,dc=com:0000013087d7e27f12d100000003; dn: replicationCSN=0000013087d7e27f12d100000003,dc=example,dc=com,cn=changelog targetDN: uid=bjensen,ou=people,dc=example,dc=com changeNumber: 0 changes:: YWRkOiBkZXNjcmlwdGlvbgpkZXNjcmlwdGlvbjogQSB0aGlyZCBjaGFuZ2UKLQpyZXBsYW NlOiBtb2RpZmllcnNOYW1lCm1vZGlmaWVyc05hbWU6IGNuPURpcmVjdG9yeSBNYW5hZ2VyLGNuPVJvb 3QgRE5zLGNuPWNvbmZpZwotCnJlcGxhY2U6IG1vZGlmeVRpbWVzdGFtcAptb2RpZnlUaW1lc3RhbXA6 IDIwMTEwNjEzMDcxMjEwWgotCg== changeType: modify changeTime: 20110613071210Z objectClass: top objectClass: changeLogEntry targetEntryUUID: fc252fd9-b982-3ed6-b42a-c76d2546312c replicationCSN: 0000013087d7e27f12d100000003 numSubordinates: 0 replicaIdentifier: 4817 changeLogCookie: dc=example,dc=com:0000013087d7e27f12d100000003; changeInitiatorsName: cn=Directory Manager,cn=Root DNs,cn=config subschemaSubentry: cn=schema hasSubordinates: false entryDN: replicationCSN=0000013087d7e27f12d100000003,dc=example,dc=com,cn=change logIf we base64-decode the changes, we see the following.
$ base64 decode --encodedData YWRkO...gotCg== add: description description: A third change - replace: modifiersName modifiersName: cn=Directory Manager,cn=Root DNs,cn=config - replace: modifyTimestamp modifyTimestamp: 20110613071210Z -If for some reason you lose the cookie, you can start over from the earliest available change by sending a search request with no value for the cookie.
As shown above, the changes returned from a search on the external
change log include only what was actually changed. If you have applications
that need additional attributes published with every change log entry,
regardless of whether or not the attribute itself has changed, then specify
those using ecl-include and
ecl-include-for-deletes.
Set the attributes to include for all update operations with
ecl-include.$ dsconfig set-external-changelog-domain-prop --port 4444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --bindPassword password --provider-name "Multimaster Synchronization" --domain-name dc=example,dc=com --set ecl-include:"@person" --trustAll --no-promptSet the attributes to include for deletes with
ecl-include-for-deletes.$ dsconfig set-external-changelog-domain-prop --port 4444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --bindPassword password --provider-name "Multimaster Synchronization" --domain-name dc=example,dc=com --add ecl-include-for-deletes:"*" --add ecl-include-for-deletes:"+" --trustAll --no-prompt
You can limit external change log content by disabling the domain
for a base DN. By default, cn=schema and
cn=admin data are not enabled.
Prevent OpenDJ from logging changes by disabling the domain.
$ dsconfig set-external-changelog-domain-prop --port 4444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --bindPassword password --provider-name "Multimaster Synchronization" --domain-name dc=example,dc=com --set enabled:false --trustAll --no-prompt
The external change log can also work for applications that follow the Internet-Draft: Definition of an Object Class to Hold LDAP Change Records. Nothing special is required to get the objects specified for this legacy format. Such applications cannot however use the change log cookies that are shared across the replication topology, and therefore can continue to be used after failover to another replica in a multi-master replication environment.
[1] Assured replication can require, however, that the convergence happen before the client application is notified that the operation was successful.
[2] When you configure partial and fractional replication, however, you can replicate only part of a suffix, or only certain attributes on entries. Also, if you split your suffix across multiple backends, then you need to set up replication separately for each part of suffix in a different backend.