In this document we describe how to manually sync CA Dir DSAs, we have three DSAs, two of them are working fine and the third one is out of sync.
This method should be used when a DSA was offline for a significant period of time (for more than 7 days), or where the multi-write queue was purged.
Errors in CA Directory Logs:
DSA is attempting to start after a long outage, perform a recovery procedure before starting
CA Directory 12.x, 14.x
Notes about the instructions:
- CADir1 is the hostname of CA Directory Server, which is OK
- CADir2 is the hostname of CA Directory Server, which is out of sync
- CADir3 is the hostname of CA Directory Server, which is OK
- On CADir1 machine (where the dxserver "<DSAName-on-CADir1>" is running) run the command:
dxdisp <DSAName-on-CADir2>
- On CADir3 machine (where the dxserver "<DSAName-on-CADir3>" is running) run the command:
dxdisp <DSAName-on-CADir2>
- Backup the data from the good DSA ( for example, <DSAName-on-CADir1>)
To do that run the following command in the command line:
dxserver onlinebackup <DSA Name>
Backup operation may take a while.
Monitor the DSA's warning log (<DSA name>_warn_<date>.log) till the following message appears:
WARN : Dump completed, X fragments
- Alternatively, you may run "dump dxgrid-db" from DXConsole.
To connect to DXConsole you must set the password in the knowledge file of the <DSAName-on-CADir1>.dxc
- Connect to DXConsole, at the CA Dir machine <DSAName-on-CADir1> where the data is OK:
telnet localhost <dxconsole-port>
Note: By default you can connect to DXConsole only locally. To allow remote connection DSA must be re-configured.
- Run the command to dump the data
dump dxgrid-db;
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 "dump" commands will generate a file with extension ".zdb" under "dxserver/data" folder (i.e. <DSAName-on-CADir1>.zdb)
- Stop dxserver with problem (<DSAName-on-CADir2>), if it is up:
dxserver stop <DSAName-on-CADir2>
- Delete/Move all the files "<DSAName-on-CADir2>.db", "<DSAName-on-CADir2>.tx", "<DSAName-on-CADir2>.dp", "<DSAName-on-CADir2>.dx" under "dxserver/data" folder
- Copy the ".zdb" file FROM "dxserver/data" folder on CADir1 machine TO "dxserver/data" folder on CADir2 machine
- Do not copy the .TX, .DX, etc. files, copy .ZDB ONLY !
- Rename .ZDB file to .DB file and also match the DSA name on CADir2: from <DSAName-on-CADir1>.zdb rename to <DSAName-on-CADir2>.db
- On the CADir2 machine run the commands:
dxdisp <DSAName-on-CADir1>
dxdisp <DSAName-on-CADir3>
- Start the <DSAName-on-CADir2>:
dxserver start <DSAName-on-CADir2>
- Restart the <DSAName-on-CADir1> and/or CADir3 if required:
dxserver stop <DSAName-on-CADir1>
dxserver start <DSAName-on-CADir1>
In case <DSAName-on-CADir2> DSA was down for a long period of time it may be required to restart the <DSAName-on-CADir1> and/or <DSAName-on-CADir3> when you have these messages in the <DSAName-on-CADir1> and/or <DSAName-on-CADir3> logs:
----------------------------------
* [5] 20160919.112602.056 DSA_W2680 Multiwrite queue (<DSAName-on-CADir2>) greater than 100% full
* [5] 20160919.112602.065 DSA_E2760 Multiwrite: Operation disabled for DSA <DSAName-on-CADir2>
----------------------------------
After restart, the <DSAName-on-CADir1> will reconnect to <DSAName-on-CADir2> and start MW replication.
For more detailed information about MW and Synchronization, please see:
https://knowledge.broadcom.com/external/article?articleId=54088
You will have to perform the operation for each of the affected DSA's.
===========
On Windows please issue all the commands as administrator.
On Linux please use "dsa" user.
In case of vApp (Identity Suite Virtual Appliance) open ssh session as "config" user and change to "dsa" user using
su - dsa