Symantec Directory - DSA out of sync where multi-write-disp-recovery is disabled
search cancel

Symantec Directory - DSA out of sync where multi-write-disp-recovery is disabled

book

Article ID: 277776

calendar_today

Updated On:

Products

CA Directory SITEMINDER

Issue/Introduction

This KB article: CA Directory - DSA out of sync explains how to synchronize out-of-sync DSA with its peers when multi-write-disp-recovery is enabled.

But the fact is that running dxdisp commands, as described in the above article, does not make any sense when DISP recovery is disabled (and an error is returned: No Multiwrite-DISP DSA was found).

So how do we synchronize when multi-write-disp-recovery is set to 'false' in DSA configuration ?

Note: disabling multi-write-disp-recovery is required, for instance, for SiteMinder session store: Configure Symantec Directory as a Session Store

Resolution

The DSA recovery procedure in case of disabled multi-write-disp-recovery setting is similar to the procedure described in CA Directory - DSA out of sync KB article, but there are some differences.

Notes about the procedure:

  • CADIR1 is the machine where Symantec Directory DSA1 service is running, and that DSA is OK
  • CADIR2 is the machine where Symantec Directory DSA2 service is running, and that DSA is out of sync
  • CADIR3 is the machine where Symantec Directory DSA3 service is running, and that DSA is OK
  • All the commands are to be run in a command line as Administrator on Windows, or as the 'dsa' user on Linux (where Symantec Directory was installed by 'root' user), or as the user who installed Symantec Directory (in case of non-root Symantec Directory installation on Linux)
  • We use some DXconsole commands in the procedure. Prior to issuing DXconsole commands you need to connect to DXconsole using telnet.
    See this document about DXconsole: DSA console
    To exit DXconsole use this command:

    logout;

    Note: all DXconsole command must have semicolon at the end.

  • You need to replace DSA1 and DSA2 with corresponding DSA names in your environment in the commands
  1. Ensure that DSA2 service is not running.
    Run the following command on CADIR2 machine:

    dxserver stop DSA2

  2. Empty multi-write queues in both DSA1 and DSA3 services.
    Open DXconsole on both CADIR1 and CADIR3 machines and issue this command:

    clear multi-write-queue DSA2;

    The above command ensures that there are no updates for DSA2 in multi-write queues in DSA1 and DSA3 services before backup from a good DSA is taken.
  3. Backup the data from the good DSA (in our example we use DSA1)
    To do that run the following command in the command line on CADIR1 machine:

    dxserver onlinebackup DSA1

    Alternatively, you may open DXConsole on CADIR1 machine and run the following command

    dump dxgrid-db;

    Please note that backup operation may take a while. You need to monitor the DSA's warning log (<DSA name>_warn_<date>.log) till the following message appears:

    WARN : Dump completed, X fragments

    The above 'dxserver onlinebackup' or DXconsole 'dump' commands will generate a file with DSA name and '.zdb' extension under 'dxserver/data' folder (dxserver/data/DSA1.zdb in our example)

  4. Delete/Move all the DSA2 data files in 'dxserver/data' folder on CADIR2 machine (in our example DSA2.db, DSA2.tx files)
    Note: .dp and .dx files, mentioned in the CA Directory - DSA out of sync KB article, are not created when DISP recovery is disabled

  5. Copy the only DSA1.zdb file from 'dxserver/data' folder on CADIR1 machine to 'dxserver/data' folder on CADIR2 machine (do not copy DSA1.tx)

  6. Rename DSA1.zdb file to DSA2.db on CADIR2 machine

  7. Start DSA2 service.
    Run the following command on CADIR2 machine:

    dxserver start DSA2