I've looked at the CA Directory Admin Guide and yes are correct, there should be an example. I will follow up on this. In the mean time, assuming you are using text-based configuration (not DXmanager):
Say we have two DSAs on two servers
server1: dsa1
server2: dsa2
To enable multi-write replication with DISP recovery (MW-DISP) on UNIX (procedure same for Windows just different paths/env vars).
Stop DSAs
server1: dxserver stop dsa1
server2: dxserver stop dsa2
Enable multi-write on server1: $DXHOME/config/knowledge/dsa1.dxc
set dsa "dsa1" =
{
prefix = <c US><o CA>
dsa-name = <c US><o CA><cn "dsa1">
dsa-password = "secret"
address = tcp "{hostname}" port 20000
disp-psap = DISP
snmp-port = 20000
console-port = 20001
auth-levels = anonymous, clear-password
dsa-flags = multi-write
trust-flags = allow-check-password
};
Enable multi-write on server1: $DXHOME/config/knowledge/dsa2.dxc.
If this file doesn't exist copy from server2, for example, copy server2: $DXHOME/config/knowledge/dsa2.dxc to server1: $DXHOME/config/knowledge
set dsa "dsa2" =
{
prefix = <c US><o CA>
dsa-name = <c US><o CA><cn "dsa2">
dsa-password = "secret"
address = tcp "{hostname}" port 20000
disp-psap = DISP
snmp-port = 20000
console-port = 20001
auth-levels = anonymous, clear-password
dsa-flags = multi-write
trust-flags = allow-check-password
};
Note: The prefix must be the same for dsa1 and dsa2 for replication to work
Create a knowledge group server1: $DXHOME/config/knowledge/dsas.dxg
source "dsa1.dxc";
source "dsa2.dxc";
Note: If a knowledge group file already exists for dsa1 and dsa2, this can be updated to ensure that both dsa1 and dsa2 are sourced.
Update server1: $DXHOME/config/servers/dsa1.dxi to source knowledge group and also enable MW-DISP while there
Locate the following line
clear dsas;
source "../knowledge/dsa1.dxc";
And replace with
clear dsas;
source "../knowledge/dsas.dxg";
To enable MW-DISP locate the following line
# multiwrite DISP recovery
set multi-write-disp-recovery = false;
And replace with
# multiwrite DISP recovery
set multi-write-disp-recovery = true;
Check for syntax errors
server1: dxsyntax dsa1
Copy the following files to server2
Copy server1: $DXHOME/config/knowledge/dsa1.dxc server2: $DXHOME/config/knowledge
Copy server1: $DXHOME/config/knowledge/dsa2.dxc server2: $DXHOME/config/knowledge
Copy server1: $DXHOME/config/knowledge/dsas.dxg server2: $DXHOME/config/knowledge
Note: It is a good idea to update the knowledge on one server and copy. This keeps them consistent!
Update server2: $DXHOME/config/servers/dsa2.dxi to source the newly copied knowledge group and also enable MW-DISP while there
Locate the following line
clear dsas;
source "../knowledge/dsa1.dxc";
And replace with
clear dsas;
source "../knowledge/dsas.dxg";
To enable MW-DISP locate the following line
# multiwrite DISP recovery
set multi-write-disp-recovery = false;
And replace with
# multiwrite DISP recovery
set multi-write-disp-recovery = true;
Do the DSAs contain data?
If the DSAs contain data and the data is synchronized (loads from the same LDIF for example) then when enabling MW-DISP it is important to checkpoint the DSAs.
server1: dxdisp dsa2
server2: dxdisp dsa1
This step prevents existing data from being superfluously replicated.
Start the DSAs
server1: dxserver start dsa1
server2: dxserver start dsa2
Check Replication is Ok
It is important to check that the DSAs have contacted each other and the state of replication is ok.
server1: telnet localhost 20001
server1: get dsp;
server1: logout;
...
...
multi-write-group-credit = 0
multi-write-outstanding-ops = 10
dsa2: OK, total 0, waiting remote 0, confirmed local 0
server2: telnet localhost 20001
server2: get dsp;
server2: logout;
...
...
multi-write-group-credit = 0
multi-write-outstanding-ops = 10
dsa1: OK, total 0, waiting remote 0, confirmed local 0
For the output of "get dsp;" we are looking for the replicating queue status to be OK. Anything other than OK like DISP-FAILED indicates either a replication problem or a connectivity problem between the two DSAs. The warn-log and alarm-log a good places to start when diagnosing these kinds of replication problems.
Another sanity test is to connect to dsa1 via an LDAP browser (like JXplorer) and perform a modify. Then connect to dsa2 and ensure the update has been replicated. A similar test for MW-DISP can be performed by stop dsa2 before updating dsa1. When dsa2 is started it will recov0r from dsa1 and the update should be reflected.
Other considerations
* We would also recommend running one or more router DSAs with the replicas to allow for automatic failover and failback
* Ensuring $DXHOME/config/knowledge are identical between machines will ensure that all DSAs will function in a consistent manner
* We would recommend setting one of the replicas as a preferred master. This is achieved adding the following line to the router.dxi file: "set write-precedence = dsa1, dsa2;". This prevents update conflicts (same entry updated at the same time on dsa1 and dsa2).
In Summary
- We ensured the that the 2 DSAs have the same prefix
- We set dsa-flags = multi-write in the knowledge file for both DSAs
- We ensured that the knowledge files for both DSAs were copied to each server and sourced via a knowledge group file
- We then sourced this knowledge group from each initialization file (.dxi) instead of sourcing the individual knowledge file for the DSA
- We enabled MW-DISP by changing multi-write-disp-recovery from true to false
- We check pointed the data if any pre-existing data after ensuring that the data is synchronized
- We then verified replication was working as expected
I hope that helps in enabling MW-DISP with 2 DSAs. Please let me know if you have any further queries. I will talk to our tech writing team to ensure an example like the above is included to assist in setting up 2 replication peers.