IBM TDS Replication Synchronization Issue resolution steps

TDS Replication Synchronization Issue resolution steps:

This is applicable for TDS versions 6.0 or above.

This example procedure uses the following two servers:

server1: the primary server with an authoritative copy of the data
server2: secondary server being setup as a replica or secondary peer

and both are running the same OS and in this example, both ldap instances are named 'ldapdb2'. This also assumes both servers have the same copy of the schema files.

For the sake of the simplicity of these instructions, this assumes all commands are being run as 'root' or 'Administrator'. Note that some commands provide a Webadmin method and a command line method. Choose one or the other.

1) Stop server2:

ibmslapd -I ldapdb2 -k

2) Quiesce subtrees from the command line:

From webadmin:

Replication management --> Manage topology --> Select the subtree --> Click the "Quiesce/Unquiesce" button

Command line:

idsldapexop -D <admin_dn> -w <password> -op quiesce -rc <replication_subtree>

This is required to make sure no changes will come in while exporting to ldif (otherwise the exported ldif file will be out of sync with the server it's exported from).

3) Skip all blocking entries for the queue from server1 to server2:

Webadmin:

Replication management --> Manage queues --> Select the queue --> Click the "Queue details" button --> Click the "Skip all" button on the "Pending changes" tab.

Command line:

idsldapexop -D <admin_dn> -w <password> -op controlqueue -skip all -ra <replication_agreement>

The replication agreement DN can be determined with the following search:

idsldapsearch -D <admin_dn> -w <password> -b <replication_subtree> objectclass=ibm-replicationAgreement dn

4) Export the data from server1 into an ldif file:

idsdb2ldif -I ldapdb2 -o server1.ldif

5) Unquiesce the queues on server1:

Webadmin:

Replication management --> Manage topology --> Select the subtree --> Click the "Quiesce/Unquiesce" button

Command line:

idsldapexop -D <admin_dn> -w <password> -op quiesce -rc <replication_subtree> -end

Once the export to ldif is finished, we can unquiesce the queues. Changes will build up in the queue (this is expected) while server2 is down. Once this process is completed and server2 is restarted, these updates will be sent to server2 allowing both servers to be in sync.

6) Make a backup copy of your ibmslapd.conf file: you may need the information in it to know how to recreate your database. Step 7 won't delete the file, but it will remove the relevant database config information.

7) Drop (delete) just the database on server2 while retaining the directory and db2 instances as is.:

idsucfgdb -I ldapdb2 -r ## respond to the prompts to destroy the database

We have to unconfigure the database or else the idsldif2db or idsbulkload will fail.

8) Crypto sync the servers if they aren't already:

***This step can be skipped if the instances are already crypto-sync'd.***

If the instances aren't crypto-sync'd yet, copy the ibmslapddir.ksf file from the instance location's etc directory from server1 to the same location on server2. The default instance location is usually the instance owner's home directory; eg: /home/ldapdb2/idsslapd-ldapdb2/etc.

Here's an example of an scp command using ldapdb2 that would copy the ibmslapddir.ksf file from server1 to server2:

scp /home/ldapdb2/idsslapd-ldapdb2/etc/ibmslapddir.ksf ldapdb2@server2:/home/ldapdb2/idsslapd-ldapdb2/etc

NOTE:

1. This method of crypto-sync can ONLY be performed when the database on server2 is not created yet.
2. Do not move or copy the ibmslapdcfg.ksf file. Each server instance can only use the copy of this file the instance was created with.

9) Schema sync the servers if they aren't already:

***This step can be skipped if the servers are already Schema-sync'd.***

To find if the instance's ldap schema files are in sync, do use the following commands in instance location's etc directory on both server1 and server2 and compare the same:
e.g.:

cd /home/ldapdb2/idsslapd-ldapdb2/etc
ls -l V3*
cksum V3*

If the servers aren't Schema sync'd yet, copy all the V3.* files from the instance location's etc directory from server1 to the same location on server2. The default instance location is usually the instance owner's home directory; e.g.: /home/ldapdb2/idsslapd-ldapdb2/etc.

Here's an example of an scp command using ldapdb2 that would copy all the V3* files from server1 to server2:

scp /home/ldapdb2/idsslapd-ldapdb2/etc/V3* ldapdb2@server2:/home/ldapdb2/idsslapd-ldapdb2/etc/

NOTE:

1. This method of Schema-sync can ONLY be performed when the database on server2 is not created yet.

10) Reconfigure the database on server2:

idscfgdb -I <instance> -a <instance_user> -w <instance_passwd> -l <instance_location> -t <database_name>

Here's an example of configuring the database using the oft-used 'ldapdb2' user:

idscfgdb -I ldapdb2 -a ldapdb2 -w password -l /home/ldapdb2 -t ldapdb2

Make sure the command completes successfully.

11) Import data on server2:

idsldif2db -I ldapdb2 -i server1.ldif -r no

or

idsbulkload -I ldapdb2 -i server1.ldif

Bulkload is much faster, but because of the way it works, also doesn't handle errors at all. Since we've dropped/recreate the database, bulkload should be fine.

Because we only recreated the database, all the suffixes that existed before still exist in the ibmslapd.conf file.

12) Optimize the database:

After adding a lot of data to the server, the DB2 table statistics need to be regenerated. You can do this by running: "idsrunstats -I <instance>" from our install 'sbin' directory.
e.g.:
idsrunstats -I ldapdb2

13) Start the server or configure as desired.

Upon restart, all the changes that have built up on server1 while this process has been doing should be replicated to server2, putting the servers right back in perfect sync.

For more reference you can use the below link.......

 http://www-01.ibm.com/support/docview.wss?rs=767&uid=swg21396012

but this link might change because ibm never keeps these kinds of links for more time