MSA for failover

[Former Member]

How can MSA be set-up and configured for failing over?

The architecture would be a Primary and a Replicate. I would need to be able to fail over to the Replicate, promoting it to a primary status.

The former replicate would then be the Primary and would replicate to the former Primary (new replicate).

Is this doable using MSA?

[former_member350489]

Hi Michael

We ran the setup similar to what Dale describes, replicating about ten user databases (full db_rep_def and db_subscription) for about two years, and to be honest it was both a pain to setup and always caused us problems after a switch. The actual problems, apart from that the switch took nearly 10 minutes, was always that after a switch (including quiesce of the two repservers X 2 times that took ages), the replication never started to flow from the new Primary to the new Replicate on at least 2-3 databases every time. So we had to drop the setup for these and materialize them from scratch to get the replication going again.

But since about nearly a year now, we run the setup described by Luc, without having to even touch any of the repservers during a switch, only stopping and starting the rep_agents. And this works like a charm

Initially we have to setup replication in both direction of course

Our steps in a switch looks like this and takes us less than 30 seconds these days :

1. Set both PRIM and SECO to unknown

2. Throw all users out of PRIM

3. Create a rs_ticket on each database on PRIM.

4. Wait for the tickets to arrive on SECO. Once they are all there, we know we have consistency.

5. Stop replication agent on PRIM

6. Remove Secondary Truncation Point for SECO

7. Set Secondary Truncation Point for SECO

8. Reset zeroltm for SECO

9. Start replication agent on SECO

10. Create rs_ticket on each database on SECO

11. Wait for the tickets to arrive on PRIM. Once they are all there, we know replication is working.

12. Remove secondary truncation point on PRIM

13. Set SECO to PRIM and vice versa

14. Done!

Note : step 1 and step 13 is our way to direct our applications against the Primary ASE (apart from IP and DNS), having a non-replicated database/table that all our apps is checking against which ASE is Primary and Replicate. And on top of this, we have a login_trigger, that will refuse login if the ASE is set to SECO (=Replicate)

/Mike

P.S And by the way, many thanks for this tip, Luc !!!

[Former Member]

What exactly do you mean by "Set both Prim and Seco to unknown" in step 1?

[former_member350489]

As I wrote in the "Note", that relates to an internal table that we use on both our ASE's, and is placed in a non replicated database. It can have three different states; PRIM, SECO and ????. The ???? is referred to as "unknown". Users/applications are only allowed to access the ASE if the state is set to PRIM. And ???? (unknown) is one state the ASE can have during the switch, as we never allow both ASE's to be PRIM (then we would really be in trouble).

So before the switch the ASE's has status PRIM-SECO

During the switch we set them both to ????-???? in step 1 to make sure noone can access them

After the switch we first set the new Primary ????-PRIM

and then the old Primary SECO-PRIM

Do you copy, over ?

[former_member214567]

Hi Michael,

MSA can be used in a standby like fashion. It is described in the Administration guide volume 1 under Manage Replicated Objects using Multisite Availability.

Here is a link the example on setting up a primary with 2 backups. It can easily be modified to your scenario:

Http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc32511.1570/doc/html/san12...

The main difference between this and warmstandby is that you will not have the switch active command to finish replication in one direction before replicating in the other direction. You will have to manage the timing yourself. For example, you will have to make sure the queues to the replicate are caught up(quiesced) before your move your users to the standby copy and begin replicating in the other direction.

Dale Newth

SAP Active Global Support