Using the command line

You can use the information and commands provided here at the command line to create a new replicated subtree.

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, have a configured database, and have been started at least once for initialization purposes. The suffix of the replicated subtree must already be configured on other servers. (Be sure to read Synchronizing two-way cryptography between server instances, in the IBM® Security Verify Directory documentation under the Administering section before you start the server instances.)

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
```

In this example the topology is more complex. It includes two peer-masters (server1 and server5), two forwarders (server2 and server4) and four replicas (server3, server6, server7, and server8). The relationship among the servers is as follows:

The illustration shows two peer servers with two forwarding servers as consumers. Each forwarding server has two replica servers as its consumers. — Figure 1. A peer-to-peer topology

server1 and server5 are peer-master servers. That means that while they receive updates from each other, they only replicate entries received from clients. While both masters have the same entry content, only the server that has received the client request replicates the entry. Both masters are suppliers and consumers to each other and suppliers to the forwarding servers.
server2 and server4 have two roles. They are both consumers of server1 and server5 and suppliers to their respective replicas. They do not perform any client updates. They pass replicated updates to their consumers. In this scenario
- server2 is a supplier to server3 and server6
- server4 is a supplier to server7 and server8
There is no interaction between server2 and server4.
replica 1 and replica 2 are consumers of server2 and server7 and server8 are consumers of server4.

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

To create the peer-masters (server1 and server5), the forwarders (server2 and server4), and the replicas (server3, server6, server7, and server8) for the subtree o=sample using offline method:

Start servers server1 and server5 in configuration mode. On each of the servers issue the command:
```
idsslapd -I <instance_name> -a
```
You must configure server1 and server5 to be peer servers. Use the idsldapadd command to add the following entry to the ibmslapd.conf file on server1 and server5. On server1 and server5 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: secret123
```
Note: It is critical that these entries be exactly the same on both servers because this example uses a credentials object that is shared on all the servers. The ibm-slapdMasterDN must be unique and cannot be same as any already existing DN's.
Stop server1 and server5. To stop the servers issue the following command on each of the servers:
```
idsslapd -I <instance_name> -k
```
where <instance_name>is the name of the directory server instance you want to stop.
Make sure that you have a backup of the ibmslapd.conf file.

At the computer where the master server, server1, is located, create a file to contain the agreement information; for example, mycredentialsfile, where mycredentialsfile contains the following information:

dn: cn=replication,cn=IBMpolicies \
objectclass: container

###Bind Credentials/method to peer/forwarder server - replication agreement
###points to this.
dn: cn=simple,cn=replication,cn=IBMpolicies
objectclass: ibm-replicationCredentialsSimple
cn: simple
replicaBindDN: cn=any
replicaCredentials: secret123
description: Bind method of the master to the peer/forwarder

The replicaBindDN and replicaCredentials values should match ibm-slapdMasterDN and ibm-slapdMasterPW values respectively from master server entry in step 2.

Issue the following command:

idsldif2db -i<mycredentialsfile> -I <instance_name>

Stop server2 and server4. To stop the servers, issue the following command on each of the servers:
```
ibmslapd -I <instance_name> -k
```
where <instance_name>is the name of the directory server instance you want to stop.
Copy the <mycredentialsfile> file to the computers where server5, server2, and server4 are located and issue the following command on each computer:
```
idsldif2db -i<mycredentialsfile> -I <instance_name>
```

At the computer where server1 is located create a file, <mytopologyfile>, where <mytopologyfile> includes:

Note: Replace all occurrences of <master-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 using the grep command on the ibmslapd.conf file, if you have an AIX®, Linux™, or Solaris system. Similarly, all occurrences of the <serverx-uuid> (where x represents a number) must be replaced with the value of the ibm-slapdServerId attribute from the respective server's cn=Configuration entry.

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

#server1 supplier entry
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: server 1 (peer supplier) ibm-replicaSubentry

#server5 supplier entry
dn: ibm-replicaServerId=<server5-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server5-uuid>
ibm-replicationServerIsMaster: true
cn: server5
description: server5 (peer supplier) ibm-replicaSubentry

#server2 forwarder entry
dn: ibm-replicaServerId=<server2-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server2-uuid>
ibm-replicationServerIsMaster: false
cn: server2
description: server 2 (forwarder) ibm-replicaSubentry

#server4 forwarder entry
dn: ibm-replicaServerId=<server4-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server4-uuid>
ibm-replicationServerIsMaster: false
cn: server4
description: server4 (forwarder) ibm-replicaSubentry

#server1 to server5 agreement
dn: cn=server5,ibm-replicaServerId=<server1-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server5
ibm-replicaConsumerId: <server5-uuid>
ibm-replicaUrl: ldap://server5:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server1(peer supplier) to server5(peer supplier) agreement

#server1 to server2 agreement
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=simple,cn=replication,cn=IBMpolicies
description: server1(peer supplier) to server2(forwarder) agreement

#server1 to server4 agreement
dn: cn=server4,ibm-replicaServerId=<server1-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server4
ibm-replicaConsumerId: <server4-uuid>
ibm-replicaUrl: ldap://server4:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server1(peer supplier) to server4(forwarder) agreement

#server5 to server1 agreement
dn: cn=server1,ibm-replicaServerId=<server5-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server1
ibm-replicaConsumerId: <server1-uuid>
ibm-replicaUrl: ldap://server1:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server5(peer supplier) to server1(peer supplier) agreement

#server5 to server2 agreement
dn: cn=server2,ibm-replicaServerId=<server5-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=simple,cn=replication,cn=IBMpolicies
description: server5(peer supplier) to server2(forwarder) agreement

#server5 to server4 agreement
dn: cn=server4,ibm-replicaServerId=<server5-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server4
ibm-replicaConsumerId: <server4-uuid>
ibm-replicaUrl: ldap://server4:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server5(peer supplier) to server4(forwarder) agreement

#server2 to server3 agreement
dn: cn=server3,ibm-replicaServerId=<server2-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server3
ibm-replicaConsumerId: <server3-uuid>
ibm-replicaUrl: ldap://server3:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server2(forwarder) to server3(replica) agreement

#server2 to server6 agreement
dn: cn=server6,ibm-replicaServerId=<server2-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server6
ibm-replicaConsumerId: <server6-uuid>
ibm-replicaUrl: ldap://server6:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server2(forwarder) to server6(replica) agreement

#server4 to server7 agreement
dn: cn=server7,ibm-replicaServerId=<server4-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server7
ibm-replicaConsumerId: <server7-uuid>
ibm-replicaUrl: ldap://server7:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server4(forwarder) to server7(replica) agreement

#server4 to server8 agreement
dn: cn=server8,ibm-replicaServerId=<server4-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server8
ibm-replicaConsumerId: <server8-uuid>
ibm-replicaUrl: ldap://server8:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server4(forwarder) to server8(replica) agreement

To load this topology, issue the command:
```
idsldif2db -r no -i<mytopologyfile> -I <instance_name>
```
where -r no prevents replication of the set of entries.
At this point you might want to load additional data for your subtree.
Note: Use the -r no flag to prevent replication of the set of entries.
When you have finished loading the data, to be able to export the topology to populate the other servers, issue the command:
```
idsdb2ldif -s "o=sample" -o <server1data.ldif> -I <instance_name> \
          -k <key seed> -t <key salt>
```
Note: You must use the -I option if there is more than one instance. You must use the -k and -t options if keys on the server are not synchronized. See the idsdb2ldif command in the Command Reference for more information.

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, in the IBM Security Verify Directory documentation under the Administering section for information about cryptographic synchronization of servers.When the source server (the server you are exporting data from) and the destination server (the server into which you will be importing the data) are using non-matching directory key stash files, and you specify the encryption seed and salt values of the destination server, any AES-encrypted data will be decrypted using the source server's AES keys, then re-encrypted using the destination server's encryption seed and salt values. This encrypted data is stored in the LDIF file. The encryption seed is used to generate a set of AES secret key values. These values are stored in a directory stash file and used to encrypt and decrypt directory stored password and secret key attributes. The encryption seed must contain only printable ISO-8859-1 ASCII characters with values in the range of 33 to 126, and must be a minimum of 12 and a maximum of 1016 characters in length. See ASCII characters from 33 to 126 , in the IBM Security Verify Directory documentation under the Administering section for information about these characters.The encryption salt is a randomly generated value that is used to generate AES encryption keys. You can obtain the destination server's salt value by searching (using the idsldapsearch utility) the destination server's "cn=crypto,cn=localhost" entry. The attribute type is ibm-slapdCryptoSalt.
Start server2, server3, server4, server6, server7, and server8 in configuration only mode. On each of the servers issue the command:
```
idsslapd -I <instance_name> -a
```
You must configure server2 and server4 to be forwarding servers and configure server3, server6, server7, and server8 to be replica servers. Use the idsldapadd command to add the following entry to the ibmslapd.conf file on each of the servers:
```
idsldapadd -D <adminDN> -w<adminPW> -p <port> -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/
```
The ibm-slapdMasterDN and ibm-slapdMasterPW values should match replicaBindDN and replicaCredentials values respectively from credential entry in step 5.
Note: This ensures that all updates from the clients are referred to server1.
Stop server2, server3, server4, server6, server7, and server8. To stop the servers, issue the following command on each of the servers:
```
ibmslapd -I <instance_name> -k
```
where <instance_name>is the name of the directory server instance you want to stop.
Save the ibmslapd.conf file as a new backup.
Copy the <server1data.ldif> file to the computers where server2, server3, server4, server5, server6, server7, and server8 are located.
At each of these computers, issue the following command:
```
idsldif2db -r no -i <server1data.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).
Start server1, server2, server3, server4, server5, server6, server7, and server8. On each of the servers issue the command:
```
idsslapd -I <instance_name>
```

To create the peer-masters (server1 and server5), the forwarders (server2 and server4), and the replicas (server3, server6, server7, and server8) for the subtree o=sample using online method:

Assumes the server server1 is already loaded with necessary data and is up and serving client applications. If required start the server1 with the command:
```
ibmslapd -I <instance_name> -n
```
Start servers server5, server2, server4, server3, server6, server7 and server8 in configuration mode. Issue the command on each of these servers:
```
ibmslapd -I <instance_name> -a
```
Use the idsldapadd command to add the following entry to the ibmslapd.conf file on all servers server1, server5, server2, server4, server3, server6, server7 and server8. On each server 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: secret123
```
Note: It is critical that these entries be exactly the same on all servers because this example uses a credentials object that is shared on all the servers. The ibm-slapdMasterDN must be unique and cannot be same as any already existing DN's.
Only on server1, re-read the updated configuration into the running ibmslapd process. Issue the command on server1:
```
idsldapexop -D <adminDN> -w <adminPW> -op readconfig -scope entire
```
Stop servers server5, server2, server4, server3, server6, server7 and server8. To stop the server issue the following command on each of these servers:
```
ibmslapd -I <instance_name> -k
```
Create a backup of the ibmslapd.conf file.

At the computer where the primary server, server1, is located, create a file to contain the agreement information; for example, mycredentialsfile, where mycredentialsfile contains the following information:

dn: cn=replication,cn=IBMpolicies
objectclass: container

###Bind Credentials/method to peer/forwarder server - replication agreement
###points to this.
dn: cn=simple,cn=replication,cn=IBMpolicies
objectclass: ibm-replicationCredentialsSimple
cn: simple
replicaBindDN: cn=any
replicaCredentials: secret123
description: Bind method of the master to the peer/forwarder

The replicaBindDN and replicaCredentials values should match ibm-slapdMasterDN and ibm-slapdMasterPW values respectively from master server entry in step 3.

Issue the command on server1:

idsldapadd -D <adminDN> -w <adminPW> -i<mycredentialsfile>

Copy the <mycredentialsfile> file to the each of servers server5, server2, server4, server3, server6, server7 and server8 are located and issue the following command on each computer:
```
idsldif2db -i <mycredentialsfile> -I <instance_name>
```

At the computer where server1 is located create a file, <mytopologyfile>, where <mytopologyfile> includes:

Note: Replace all occurrences of <master-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 using the grep command on the ibmslapd.conf file, if you have an AIX, Linux, or Solaris system. Similarly, all occurrences of the <serverx-uuid> (where x represents a number) must be replaced with the value of the ibm-slapdServerId attribute from the respective server's cn=Configuration entry.

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

#server1 supplier entry
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: server 1 (peer supplier) ibm-replicaSubentry

#server5 supplier entry
dn: ibm-replicaServerId=<server5-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server5-uuid>
ibm-replicationServerIsMaster: true
cn: server5
description: server5 (peer supplier) ibm-replicaSubentry

#server2 forwarder entry
dn: ibm-replicaServerId=<server2-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server2-uuid>
ibm-replicationServerIsMaster: false
cn: server2
description: server 2 (forwarder) ibm-replicaSubentry

#server4 forwarder entry
dn: ibm-replicaServerId=<server4-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: <server4-uuid>
ibm-replicationServerIsMaster: false
cn: server4
description: server4 (forwarder) ibm-replicaSubentry

#server1 to server5 agreement
dn: cn=server5,ibm-replicaServerId=<server1-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server5
ibm-replicaConsumerId: <server5-uuid>
ibm-replicaUrl: ldap://server5:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server1(peer supplier) to server5(peer supplier) agreement
ibm-replicationOnHold: TRUE

#server1 to server2 agreement
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=simple,cn=replication,cn=IBMpolicies
description: server1(peer supplier) to server2(forwarder) agreement
ibm-replicationOnHold: TRUE

#server1 to server4 agreement
dn: cn=server4,ibm-replicaServerId=<server1-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server4
ibm-replicaConsumerId: <server4-uuid>
ibm-replicaUrl: ldap://server4:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server1(peer supplier) to server4(forwarder) agreement
ibm-replicationOnHold: TRUE

#server5 to server1 agreement
dn: cn=server1,ibm-replicaServerId=<server5-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server1
ibm-replicaConsumerId: <server1-uuid>
ibm-replicaUrl: ldap://server1:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server5(peer supplier) to server1(peer supplier) agreement
ibm-replicationOnHold: TRUE

#server5 to server2 agreement
dn: cn=server2,ibm-replicaServerId=<server5-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=simple,cn=replication,cn=IBMpolicies
description: server5(peer supplier) to server2(forwarder) agreement
ibm-replicationOnHold: TRUE

#server5 to server4 agreement
dn: cn=server4,ibm-replicaServerId=<server5-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server4
ibm-replicaConsumerId: <server4-uuid>
ibm-replicaUrl: ldap://server4:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server5(peer supplier) to server4(forwarder) agreement
ibm-replicationOnHold: TRUE

#server2 to server3 agreement
dn: cn=server3,ibm-replicaServerId=<server2-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server3
ibm-replicaConsumerId: <server3-uuid>
ibm-replicaUrl: ldap://server3:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server2(forwarder) to server3(replica) agreement
ibm-replicationOnHold: TRUE

#server2 to server6 agreement
dn: cn=server6,ibm-replicaServerId=<server2-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server6
ibm-replicaConsumerId: <server6-uuid>
ibm-replicaUrl: ldap://server6:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server2(forwarder) to server6(replica) agreement
ibm-replicationOnHold: TRUE

#server4 to server7 agreement
dn: cn=server7,ibm-replicaServerId=<server4-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server7
ibm-replicaConsumerId: <server7-uuid>
ibm-replicaUrl: ldap://server7:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server4(forwarder) to server7(replica) agreement
ibm-replicationOnHold: TRUE

#server4 to server8 agreement
dn: cn=server8,ibm-replicaServerId=<server4-uuid>,ibm-replicaGroup=default,o=sample
objectclass: top
objectclass: ibm-replicationAgreement
cn: server8
ibm-replicaConsumerId: <server8-uuid>
ibm-replicaUrl: ldap://server8:389
ibm-replicaCredentialsDN: cn=simple,cn=replication,cn=IBMpolicies
description: server4(forwarder) to server8(replica) agreement
ibm-replicationOnHold: TRUE

To load this topology, issue the command:
```
idsldapadd -D <adminDN> -w <adminPW> -l -i <mytopologyfile>
```
where -l option prevents replication of the set of entries.
Now the server1 is aware of the peer server5, forwarder servers server2 and server5. server1 keeps track of all changes (updates) in the suspended replication queues to server5, server2 and server4.
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.
Export the server1 data (which also includes replication topology information) for the replication context, issue the command on server1:
```
idsdb2ldif -s "o=sample" -o <server1data.ldif> -I <instance_name> \
		-k <key seed> -t <key salt>
```
Note: You must use the -I option if there is more than one instance. You must use the -k and -t options if keys on the server are not synchronized. See the idsdb2ldif command in the Command Reference for more information.

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, in the IBM Security Verify Directory documentation under the Administering section for information about cryptographic synchronization of servers.When the source server (the server you are exporting data from) and the destination server (the server into which you will be importing the data) are using non-matching directory key stash files, and you specify the encryption seed and salt values of the destination server, any AES-encrypted data will be decrypted using the source server's AES keys, then re-encrypted using the destination server's encryption seed and salt values. This encrypted data is stored in the LDIF file. The encryption seed is used to generate a set of AES secret key values. These values are stored in a directory stash file and used to encrypt and decrypt directory stored password and secret key attributes. The encryption seed must contain only printable ISO-8859-1 ASCII characters with values in the range of 33 to 126, and must be a minimum of 12 and a maximum of 1016 characters in length. See ASCII characters from 33 to 126 , in the IBM Security Verify Directory documentation under the Administering section for information about these characters.The encryption salt is a randomly generated value that is used to generate AES encryption keys. You can obtain the destination server's salt value by searching (using the idsldapsearch utility) the destination server's "cn=crypto,cn=localhost" entry. The attribute type is ibm-slapdCryptoSalt.
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
```
Save the ibmslapd.conf file as a new backup on all servers.
Copy the <server1data.ldif> file to the computers where server5, server2, server4, server3, server6, server7, and server8 are located.
At each of these servers server5, server2, server4, server3, server6, server7, and server8, issue the following command:
```
idsldif2db -r no -i <server1data.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 each of servers server5, server2, server4, server3, server6, server7, and server8, issue the command idsrunstats to optimize the table statistics:
```
idsrunstats -I <instance_name>
```
Start ibmslapd on each of the servers server1, server2, server3, server4, server5, server6, server7, and server8. Issue the command:
```
idsslapd -I <instance_name> -n
```

On the server2, resume the suspended replication agreement to server3 and server6. Issue the command on server2:

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

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

On the server4, resume the suspended replication agreement to server7 and server8. Issue the command on server4:

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

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

On the server5, resume the suspended replication agreement to server1, server2 and server4. Issue the command on server5:

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

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

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

On the server1, resume the suspended replication agreement to server5, server2 and server4. Issue the command on server1:

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

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

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