IBM Support

Directions for resynchronizing IBM Security Directory Server systems in a replicated topology

Question & Answer


Question

This technote provides the procedure to sync two servers so they have the exact same copy of data (so, for example, to prevent replication from blocking)

Cause

When data gets out of sync between replication partners, updates can block on objects that are missing from one of the servers. A common error that can occur is an error 32 while replicating an LDAP modify operation.

Answer

Here's the procedure for syncing data between two servers running 6.0 or later.

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


**Steps [2 to 5] must be done on Server1 - source of authoritative data.
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 ( Read only mode, 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 subtrees 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 <ldap_instance> -r   ## respond to the prompts to destroy the database

Here's an example of configuring the database using the LDAP instance name 'ldapdb2':

idsucfgdb -I ldapdb2 -r

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

Please consider, that ANY database that is configured with the directory server instance will be removed by this command. So if you have configured also a ChangeLog DB with this instance, then this will be removed as well at this step.
So if you need the current contents of ChangeLog please make a backup before executing the idsucfgdb command.
Otherwise the current ChangeLog data are lost.

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 <ldap_instance> -a <db_admin_user> -w <db_admin_passwd> -l <db_location> -t <db_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.

If you had a ChangeLog configured, then you have to configure this here again as well.
Use the command idscfgchglg:

    idscfgchglg -I <ldap_instancename> -m <maxentries> -y <maxdays> -h <maxhours>

Please use the backup'ed ibmslapd.conf (see step 6) for the values of <maxentries>, <maxdays> respectively <maxhours>.
Sample:
     idscfgchglg -I ldapdb2 -m 0 -y 60

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.

[{"Product":{"code":"SSVJJU","label":"IBM Security Directory Server"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Component":"General","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"6.0;6.1;6.2;6.3;6.3.1;6.4","Edition":"","Line of Business":{"code":"LOB24","label":"Security Software"}}]

Product Synonym

isds;itds;ids;secureway;tivoli directory server;directory server;tivoli;ibm directory server

Document Information

Modified date:
12 March 2021

UID

swg21396012