Using the command line

You can issue the commands provided here at the command line to create replica.

About this task

This scenario assumes that you are creating a new replicated subtree and that only server1 contains any entry data. All other servers are newly installed and have a configured database. The suffix of the replicated subtree must already be configured on other servers.

Note:

dn: o=sample
objectclass: organization
objectclass: ibm-replicationContext
o: sample

is the subtree you want to create. If this entry already exists, then modify it to add objectclass=ibm-replicationContext instead of adding the entire entry.

Create an ldif file suffix_update.ldif with the following information to add the objectclass=ibm-replicationContext to the already existing suffix or branch:
```
dn: o=sample
changetype: modify
add: objectclass
objectclass: ibm-replicationContext
```
Use the idsldapmodify command to modify the suffix entry on server1. On server1 issue the following command:
```
idsldapmodify -D <adminDN> -w <adminPW> -i suffix_update.ldif
```

To create a replica for a subtree, you need to create a replication agreement between the master and the replica, see Replication agreements. This agreement needs to be loaded on both the master and the replica.

The relationship between the two servers is that the master is a supplier to the replica and the replica is a consumer of the master.

You can use either an offline method or an online method.

To create the master (server1) and replica (server2) for the subtree o=sample using offline method:

At the machine where the master is located, create a file to contain the agreement information, for example, myreplicainfofile, where myreplicainfofile contains:

Note: Replace all occurrences of <server1-uuid> in the following files with the value of the ibm-slapdServerId attribute from the master server's cn=Configuration entry. This value is generated by the server the first time it is started. You can find it either by performing an idsldapsearch of the cn=Configuration entry or that uses the grep command on the ibmslapd.conf file, if you have a UNIX-based system. Similarly, all occurrences of the <server2-uuid> must be replaced with the value of the ibm-slapdServerId attribute from the replica server's cn=Configuration entry.

This replicaBindDN must be unique and cannot be same as any already existing DN's.

###Replica Group
dn: ibm-replicaGroup=default, o=sample
objectclass: top
objectclass: ibm-replicaGroup
ibm-replicaGroup: default

###Bind Credentials/method to replica server - replication agreement
###points to this.
dn: cn=server2 BindCredentials,cn=replication,cn=IBMpolicies
objectclass: ibm-replicationCredentialsSimple
cn: server2 BindCredentials
replicaBindDN: cn=any
replicaCredentials: secret123
description: Bind method of the master (server1) to the replica (server2)

###Replica SubEntry
dn: ibm-replicaServerId=<server1-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server1-uuid>
ibm-replicationServerIsMaster: true
cn: server1
description: master server

###Replication Agreement to the replica server
dn: cn=server2,ibm-replicaServerId=<server1-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server2
ibm-replicaConsumerId: <server2-uuid>
ibm-replicaUrl: ldap://server2:389
ibm-replicaCredentialsDN: cn=server2 BindCredentials,cn=replication, cn=IBMpolicies
description: replica server (server2)

Stop the master, if it is not already stopped.
```
ibmslapd -I <instance_name> -k
```
To load the new replication topology to the master, issue the command:
```
idsldif2db -r no -i <myreplicainfofile> -I <instance_name>
```
where -r no prevents replication of the set of entries.
To generate a file with all the data necessary to synchronize the new replica, issue the command:
```
idsdb2ldif -o <masterfile.ldif> -I <instance_name> -s o=sample -k <key seed> -t <key salt>
```
Note: Use the -I option if there is more than one instance. Use the -k and -t options if keys on the server are not in sync.

Attention: If you are exporting data that will be imported into an Advanced Encryption Standard (AES)-enabled server and if the two servers are not cryptographically synchronized, see Synchronizing two-way cryptography between server instances, for information about cryptographic synchronization of servers and the note.
See the idsdb2ldif command information in the IBM® Verify Directory Command Reference for more information.
Note: Perform steps 5 through 9 on the machine where server2 is located.
Copy <masterfile.ldif> to the replica.
Start the replica, server2, in configuration only mode.
```
idsslapd -I <instance_name> -a
```
Make sure you have a backup of the original ibmslapd.conf, ibmslapdcfg.ksf, and ibmslapddir.ksf files.
You must configure server2 to be a replica server. Use the idsldapadd command to add the following entry to the ibmslapd.conf file on server2. On server2 issue the following command:
```
idsldapadd -D <adminDN> -w <adminPW> -i<filename>
```
where <filename> contains:
```
dn: cn=Master Server, cn=configuration 
objectclass: ibm-slapdReplication 
cn: Master Server 
ibm-slapdMasterDN: cn=any 
ibm-slapdMasterPW: secret 
ibm-slapdMasterReferral: ldap://server1:389/
```
Note: The ibm-slapdMasterDN and ibm-slapdMasterPW values must match the values stored on the master server, server1, in the entry "cn=server2 BindCredentials" in step 1.
Stop the replica, server2. To stop the server issue the command:
```
idsslapd -I <instance_name> -k
```
Save the ibmslapd.conf file as a new backup.
Issue the following command to import the data in ldif file:
```
idsldif2db -r no -i <masterfile.ldif> -I <instance_name>
```
where -r no prevents replication of the set of entries. For large ldif data imports, use idsbulkload command (without -r no option).
After completing the data import on replica server, issue the command idsrunstats to optimize the table statistics:
```
idsrunstats -I <instance_name>
```
Start the master (server1) and the replica (server2). On each of the servers issue the command:
```
idsslapd -I <instance_name> -n
```

To create the master (server1) and replica (server2) for the subtree o=sample using online method:

At the machine where the master is located, create a file to contain the agreement information, for example, myreplicainfofile, where myreplicainfofile contains:

Note: Replace all occurrences of <server1-uuid> in the following files with the value of the ibm-slapdServerId attribute from the master server's cn=Configuration entry. This value is generated by the server the first time it is started. You can find it either by performing an idsldapsearch of the cn=Configuration entry or by using the grep command on the ibmslapd.conf file, if you have a UNIX-based system. Similarly, all occurrences of the <server2-uuid> must be replaced with the value of the ibm-slapdServerId attribute from the replica server's cn=Configuration entry.

This replicaBindDN must be unique and cannot be same as any already existing DN's.

###Replica Group
dn: ibm-replicaGroup=default, o=sample
objectclass: top
objectclass: ibm-replicaGroup
ibm-replicaGroup: default

###Bind Credentials/method to replica server - replication agreement
###points to this.
dn: cn=server2 BindCredentials,cn=replication,cn=IBMpolicies
objectclass: ibm-replicationCredentialsSimple
cn: server2 BindCredentials
replicaBindDN: cn=any
replicaCredentials: secret
description: Bind method of the master (server1) to the replica (server2)

###Replica SubEntry
dn: ibm-replicaServerId=<server1-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server1-uuid>
ibm-replicationServerIsMaster: true
cn: server1
description: master server

###Replication Agreement to the replica server
dn: cn=server2,ibm-replicaServerId=<server1-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server2
ibm-replicaConsumerId: <server2-uuid>
ibm-replicaUrl: ldap://server2:389
ibm-replicaCredentialsDN: cn=server2 BindCredentials,cn=replication, cn=IBMpolicies
description: replica server (server2)
ibm-replicationOnHold: TRUE

Choose a time when the master server is getting low write (update) traffic.
To add the new replication topology to the master, issue the command on the master server:
```
idsldapadd -D <adminDN> -w <adminPW> -l -i <myreplicainfofile>
```
where -l prevents replication of the set of entries.
Now the master server is aware of the replica server and keeps track of all changes (updates) in the suspended replication queue.
If you need the data synchronization to be successful, it is important to quiesce the server1 to make it read only until the data extract is completed. To quiesce the server1 issue the command:
```
idsldapexop -D <adminDN> -w <adminPW> -op quiesce -rc o=sample
```
If you need the server1 to function in read and write mode, there may be a set of replicated changes that are also going to be extracted into ldif file via idsdb2ldif.
To generate a file with all of the data necessary to synchronize the new replica, issue the command:
```
idsdb2ldif -o <masterfile.ldif> -I <instance_name> -s o=sample -k <key seed> -t <key salt>
```
Note: Use the -I option if there is more than one instance. Use the -k and -t options if keys on the server are not in sync.

Attention: If you are exporting data that will be imported into an Advanced Encryption Standard (AES)-enabled server and if the two servers are not cryptographically synchronized, see Synchronizing two-way cryptography between server instances, for information about cryptographic synchronization of servers and the note.
See the idsdb2ldif command information in the IBM Verify Directory Command Reference for more information.
After successful data export using idsdb2ldif unquiesce the server1 so that it can function in read and write mode.
```
idsldapexop -D <adminDN> -w <adminPW> -op quiesce -rc o=sample -end
```
Copy <masterfile.ldif> to the replica.
Start the replica, server2, in configuration only mode.
```
idsslapd -I <instance_name> -a
```
Make sure you have a backup of the original ibmslapd.conf, ibmslapdcfg.ksf, and ibmslapddir.ksf files.
You must configure server2 to be a replica server. Use the idsldapadd command to add the following entry to the ibmslapd.conf file on server2. On server2 issue the following command:
```
idsldapadd -D <adminDN> -w <adminPW> -i<filename>
```
where <filename> contains:
```
dn: cn=Master Server, cn=configuration 
objectclass: ibm-slapdReplication 
cn: Master Server 
ibm-slapdMasterDN: cn=any 
ibm-slapdMasterPW: secret 
ibm-slapdMasterReferral: ldap://server1:389/
```
Note: The ibm-slapdMasterDN and ibm-slapdMasterPW values must match the values stored on the master server, server1, in the entry "cn=server2 BindCredentials" in step 1.
Stop the replica, server2. To stop the server issue the command:
```
idsslapd -I <instance_name> -k
```
Save the ibmslapd.conf file as a new backup.
Issue the following command to import the data in ldif file on replica server:
```
idsldif2db -r no -i <masterfile.ldif> -I <instance_name>
```
where -r no prevents replication of the set of entries. For large ldif data imports, use idsbulkload command (without -r no option).
After completing the data import on replica server, issue the command idsrunstats to optimize the table statistics:
```
idsrunstats -I <instance_name>
```
Start the replica (server2) server. Issue the command:
```
idsslapd -I <instance_name> -n
```

On the master server, resume the suspended replication agreement:

idsldapexop -D <adminDN> -w <adminPW> -op controlrepl -action resume \
             -ra "cn=server2,ibm-replicaServerId=<server1-uuid>,ibm-replicaGroup=default,o=sample"