Q) Though both docs are authentic but they have contradciting statements. Doc1 mentions that we need to run dxdisp of good dsa on all the dsas, where as Doc2 says that we need to run dxdisp of bad dsa on all the DSAs.
Please let us know about the correct steps.
A) Doc2 is correct. You need to run 'dxdisp' only on/for recovering DSA but need to run the same command on all hosts. Running 'dxdisp' on all hosts for all DSAs that are part of MW replication is also OK as it has no ill effect. It's just extra commands you have to execute.. so technically both - only on/for recovering OR all - will be fine. Just not ONLY for good DSA. That doesn't serve the purpose.
Q) Also, though .dp files on all the dsas is getting updated daily with the latest update timestamp, but there's some data on good dsas which is not getting synced. So , can there be a specific reason for it.
A) Could be and nothing can be told just from the statement above. You may want to consider to open a support case Broadcom to find out further as DSA log review will be required for this.
Q) Please be informed that we had tried the steps mentioned in Doc2 on lower environment and were able to see that in warn logs of CA Directory it says "DataStore created for DSA2(of which we copied the .zdb file on bad dsas)". if possible please let us know the reasons for that too.
A) That is correct and by design. The dsaname (e.g. DSA2 in your example) is hard coded within the .db (and .zdb) file when it was originally created during creation of a new dsa. This cannot be removed or changed so when you perform a manual recovery, the name comes over as part of the recovery process.
If that is a problem, the other option you have is to:
** Dumpe the generated backup (e.g. DSA2.zdb) to LDIF file with dxdumpdb command line tool along with '-z' option.
** Shutdown the recovering DSAs (DSA3 and DSA4) and empty it out with 'dxemptydb' command line tool.
** Load them using the reulsting LDIF file with 'dxloaddb' command line too.
As you are working with exisiting DSA3.db and DSA4.db, the name will be preserved (as I said, it is hardcoded within the .db file) so when you start those DSAs after recovery.. it will still show "DataStore created for DSA3" and "DataStore created for DSA4" respectively.
~Hitesh
Original Message:
Sent: 09-16-2020 06:16 AM
From: Nawal Kumar
Subject: Manual Syncing of 4 CA Directories as User Stores
Hi Community,
We've 4 DSAs 2 each in 2 different data centres.
DSA1 DSA2(Data centre1)
DSA3 DSA4(Data centre2)
In our case DSA3 n DSA4 are bad dsas so we need to sync them with DSA1 n DSA2 which are good dsas.
So we want to copy the .db file of DSA2 on both bad DSAs
While researching for this we have found below below article and a CA Directory replication document
Doc1:
CA Directory DSA out of syncBroadcom | remove preview |
| CA Directory DSA out of sync | In this document we will describe how to manually sync CA Dir DSAs, we have two DSAs, one working fine and other out of sync. | View this on Broadcom > |
|
|
Doc2:
CA Directory r12 Data Replication and Recovery Best Practice | Manualzz
manualzz.com | remove preview |
| CA Directory r12 Data Replication and Recovery Best Practice | Manualzz | CA Directory r12 SP1 Data Replication & Recovery Best Practice This document provides specific advice on how to configure CA Directory r12 SP1 for replication between peer data DSAs to provide High-Availability and 24x7 service. CA Directory provides three data replication methods, multiwrite, DISP and multiwriteDISP. | View this on manualzz.com > |
|
|
Though both docs are authentic but they have contradciting statements. Doc1 mentions that we need to run dxdisp of good dsa on all the dsas, where as Doc2 says that we need to run dxdisp of bad dsa on all the DSAs.
Please let us know about the correct steps.
Also, though .dp files on all the dsas is getting updated daily with the latest update timestamp, but there's some data on good dsas which is not getting synced. So , can there be a specific reason for it
Please be informed that we had tried the steps mentioned in Doc2 on lower environment and were able to see that in warn logs of CA Directory it says "DataStore created for DSA2(of which we copied the .zdb file on bad dsas)". if possible please let us know the reasons for that too.