Skip to Content

Introduction

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.

Switching Scenarios

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:

  • The 1st scenario uses a very simple setup, which will require only a few steps but interrupts updates of the 3rd system
  • The 2nd scenario keeps the 3rd system up-to-date all the time, which requires following a strict procedure

Note that in the SLD systems in bi-directional full automatic content synchronization

  • Object server names for both
    • Internal object server names need to be different
      (Internal object server is only called object server on the SLD UI)
    • External object server names are identical
  • The Change log of each system is different, even though the content is the same

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.

1st Scenario: Switching between 2 SLDs in Sync with a 3rd System with Delay in Data Update

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:

Switching_between_2_SLDs_in_FAS_with_3rd_system_01.png

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”)

Procedure

The procedure includes switching back to the original source SLD at the end.

  1. Deactivate content sync B -> A and A -> B.
  2. Set SLD A to read-only and wait until there are no more pending changes in content sync A -> C.
  3. Deactivate content sync “A -> C”.
  4. Switch virtual IP address (VIPA, see blog How to Ensure that SLD Data is Available during Maintenance).
  5. Wait until the virtual IP address can be switched back (e.g. when the maintenance of SLD A is done). Until this time no updates are synchronized to LMDB or SLD C.
  6. Re-activate content sync “A <-> B” and content sync “A -> C”, once SLD “A” is available again.
Result

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.

2nd Scenario: Switching between 2 SLDs in Sync with a 3rd System w/o Delay in Data Update

In this 2nd scenario you avoid the 3rd system getting out-of-date by replacing the synchronization connection A -> C by B -> C:

Switching_between_2_SLDs_in_FAS_with_3rd_system_02.png

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”)

Procedure
  1. Deactivate content sync connections B -> A and A -> B.
  2. Set SLD A to read-only and wait until there are no more pending changes in content sync A -> C.
  3. Delete content sync A -> C
    (it will be replaced by a content sync B -> C; de-activating and re-activating the original content sync will not lead to the desired result because of different change logs).
  4. Switch virtual IP address (see blog How to Ensure that SLD Data is Available during Maintenance).
  5. Add content sync B -> C.
    Since change logs of SLD systems A and B are different, the content sync starts with the full sync phase, which will run for some time.

    After SLD “A” or its replacement is up again, you can use the same procedure to switch back to the original setup:

  6. Activate (bi-directional) content sync connections B -> A and A -> B and wait until there are no more pending changes in content sync B -> A.
  7. Set SLD B to read-only and wait until there are no more pending changes in content sync B -> C.
  8. Deactivate content sync B -> C.
  9. Switch virtual IP address.
  10. Create content sync “A -> C”.
    Since change logs of SLD systems A and B are different, the content sync starts with the full sync phase, which will run for some time.
Result

The 3rd system (e.g. the LMDB) will get updated during downtime of SLD A.

 

Additional Information

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Eike Gehlhaar

    hello wolf!

    interesting article! we intend to implement a central SLD similar to the 1st szenario. how should the ranks be assigned to SLD A and B in the Full-Sync?

    best regards

    e.gehlhaar

    (0) 
      1. Eike Gehlhaar

        hello wolf,

        thanks, the concept of definig ranks to avoid conflicts is familiar to me. but how would you choose the ranks in your own 1st. scenario?

        best regards,

        eg

        (0) 

Leave a Reply