In a backup setup, to keep SLD available during SLD maintenance, two SLD systems can be connected with a bidirectional full automatic content synchronization. Switching does not require actions for applications using SLD data or sending data suppliers if you use a Virtual IP Address (VIPA) – see blog “How to Ensure that SLD Data is Available during Maintenance”.
The two SLD systems may additionally be connected with a unidirectional full automatic content synchronization to a 3rd SLD or LMDB. In that case, if you need to switch between “main” and “backup” SLD, to avoid data inconsistencies, you need to follow some rules according to the switching scenario chosen.
You are in a situation that you need to switch between “main” or “central” SLD “A” and “backup” SLD “B”, for example, because you want to update the system currently in use or even migrate it to a new server. To avoid data inconsistencies, it is important to choose between the following two scenarios and act accordingly during the switching:
Note that in the SLD systems in bi-directional full automatic content synchronization
Whereas applications identify the SLD via the external object server name, the full automatic content synchronization identifies the SLD via the internal object server name. For this reason switching does not affect applications; but it does affect the content synchronization.
In this scenario you have two SLD systems in bidirectional full automatic content synchronization. Switching for the applications is done via the VIPA. You have to take care of the unidirectional synchronization connection from Central SLD to the 3rd system (e.g. LMDB) only:
Figure 1: Switching between 2 SLDs in sync with a 3rd system with delay in data update.
Inactivated sync A -> C during switch (no update of system "C" during downtime of system "A")
The procedure includes switching back to the original source SLD at the end.
Obviously, while the synchronization is deactivated, the 3rd system will get no updates. All changes that happened in the meantime will be synchronized when the synchronization connections are activated again.
In this 2nd scenario you avoid the 3rd system getting out-of-date by replacing the synchronization connection A -> C by B -> C:
Figure 2: Switching between 2 SLDs in sync with a 3rd system without delay in data update
Replaced sync A -> C during switch (B -> C updates system "C" during downtime of system "A")
The 3rd system (e.g. the LMDB) will get updated during downtime of SLD A.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
38 | |
19 | |
14 | |
12 | |
10 | |
10 | |
10 | |
8 | |
8 | |
8 |