Gastarbajter

Although I have published an article with a very similar content it does not cover another common use-case. Namely, I have wrote how to setup a multi-master replication but now I will describe another case which is single-master replication (one supplier and one consumer). This case is very similar to the MMR but simpler.

First configure the supplier:

• configure the server to use Changelog DB:

dn: cn=changelog5, cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
cn: changelog5
nsslapd-changelogdir: <path to the directory where you want DB files stored>

• configure the Replication Manager account:

dn: cn=Replication Manager, cn=replication, cn=config
changetype: modify
add: userPassword
userpassword: <replication manager password>

• now enable the replication for the suffix:

dn: cn=replica, cn=<suffix>, cn=mapping tree, cn=config
changetype: add
objectclass: top
objectclass: nsDS5Replica
cn: replica
nsDS5ReplicaRoot: <suffix>
nsDS5ReplicaID: 1
nsDS5ReplicaBindDN: cn=Replication Manager, cn=replication, cn=config
nsDS5Flags: 1
nsDS5ReplicaType: 3
nsDS5ReplicaPurgeDelay: 604800

The attributes nsDS5ReplicaID, nsDS5Flags and nsDS5ReplicaType define the role of the server in the replication hierarchy, so for the master: nsDS5ReplicaID has to be unique integer, nsDS5FLags: 1 (this means the changelog is enabled), and nsDS5ReplicaType: 3; for consumer it has to be: nsDS5ReplicaID: 65535, nsDS5Flags: 0 (do not use changelog db), nsDS5ReplicaType: 2. In case of the hub, the configuration is the same as for the consumer except that the changelog flag is set to on (nsDS5Flags: 1).

• create the replication agreement

dn: cn=<agreement name>, cn=replica, cn=<suffix name>, cn=mapping tree, cn=config
changetype: add
objectclass: top
objectclass: nsDS5ReplicationAgreement
cn: <agreement name>
description: Master to replica
nsDS5ReplicaRoot: <suffix name>
nsDS5ReplicaHost: <hostname>
nsDS5ReplicaPort: <port>
nsDS5ReplicaBindDN: cn=Replication Manager, cn=replication, cn=config
nsDS5ReplicaCredentials: <replication manager password>
nsDS5ReplicaBindMethod: SIMPLE

<agreement name> is a arbitrary string, but most usually it takes form of: <fully qualified domain name>:<port> where the FQDN is that of the server which would recieve the replica. Note that in the case this is not set to a standard name it might pose a dificulty in the upgrade to DSEE 6 because it relies on the standard name for automated migration.

<suffix name> is the base DN of the suffix you want to replicate, but bear in mind that suffixes with more then one component need to have the escape sequence. For example, in the case of having suffix „dc=example,dc=com“, the DN of the replication agreement would look like:

dn: cn=ldap-replica.example.com:389, cn=replica, cn=dc=example\,dc=com, cn=mapping tree, cn=config

On the other hand, the attribute nsDS5ReplicaRoot does not need the escape sequence so it can be written normally. For example:

nsDS5ReplicaRoot: dc=example,dc=com

<hostname> and <port> correspond to those of the server which acts as the consumer.

<replication manager password> is the password set for the cn=Replication Manager,cn=replication,cn=config entry.

FInally configure the consumer:

• create the replica: (as this is fully explained above, it can be made as a single LDIF and imported to the consumer)

dn: cn=replica, cn=<suffix>, cn=mapping tree, cn=config
changetype: add
objectClass: top
objectClass: nsDS5Replica
cn: replica
nsDS5ReplicaId: 65535
nsDS5ReplicaRoot: <suffix>
nsDS5ReplicaBindDN: cn=Replication Manager, cn=replication, cn=config
nsDS5Flags: 0
nsDS5ReplicaType: 2
nsDS5ReplicaPurgeDelay: 604800

dn: cn=Replication Manager, cn=replication, cn=config
changetype: modify
add: userPassword
userpassword: <replication manager password>

• finally, initialize the consumer: (this has to be imported to the master server)

dn: cn=<agreement name>, cn=replica, cn=<suffix>, cn=mapping tree, cn=config
changetype: modify
replace: nsDS5BeginReplicaRefresh
nsDS5BeginReplicaRefresh: start