temporary switching to warm standby database

[suznCB]

Dears,

we are planning to move our data center to a new building, so we will turn off our production server that hosts Sybase service, move it to the new data center, then start it and connect it to our network to allow users to do their tasks on applications that connect to Sybase database,

this is a happy scenario with no problems, and we expect the down time will be 5 hours as a maximum,

BUT, we also have to prepare a plan for unexpected issues which will exceed that 5 hours off,

So, for now, we have a replication server and warm standby database, which is synchronized with production db, and when we over the 5 hours off, we can switch to standby db using switch command on RepServer level, and switch client applications to the new active db by configuring DNS to connect to the new server, but after the production server will up again, maybe after 7 hours, can we take a dump from this new live db (which was a standby db), and load it on production server , and return client application to connect to the production server by DNS configuration? and if it is OK, do we have to rebuild a replication server and a new warm standby db?

please this is a critical issue, any hint will be usefull for me

Thanks in advance

[sladebe]

If I'm understanding this correctly, you're using ODBC to connect to a hostname:port? And you want to change the hostname after the switch active? Can't do that if the ASE and repservers are using the same hostname. The users have to have a hostname alias that always points to the primary ASE hosts (or interfaces name alias).

Does this work?

• Have the users access the primary ASE server(s) via an interfaces alias or a DNS name alias that is different from the ASE names used by the repservers and ASE servers.
• Setup warm standby replication from the old building to the new building
• Disable access to the primary ASE servers in the old building
• Do a repserver "switch active" so the primary ASE servers are now in the new building (actual steps are quiesce old primary, stop the rep_agent, do switch active, start the rep_agent in the new primary db)
• Update your interfaces alias or DNS name alias for the name used by the users to access the primary ASE server(s)

[bonusbrevis · Accepted solution]

Hi Suzn

Sorry if I was not very clear. What I mean is this:

Your replication is currently going from a primary server (A) to a standby server (B ) via a repserver (C) set up as a warmstandby pair.

First you suspend your users and switch replication in (C) so that now A is standby and B is primary. Now replication will move from B to A. After this completes, you disconnect the DSI's from A to C.

Now you switch users to work on B and allow them to begin work again. As users work on B, transactions accumulate in the queues of C because the connections to A are shut off.

Now move A to the new location and do whatever you need to do in it. Whether it takes 5 hours or 20 hours, transactions are still in C from users working on B, just make sure you have enough queue space in C to hold all the data of users working in B.

After you move A then you connect the DSI's to C again. All transactions that were on C will start flowing to A until the queues reach zero. At this point you suspend you user's activity and switch direction of replication in C so that A becomes the primary again and B becomes the standby again.

Now you can move the users to connect again to A and you are back to where you began, with users in A, replicating to the standby B.

Regards.

[bonusbrevis]

Suzn

From reading your description, you could do something more simple. Before you turn off the active ASE to move it, switch active and standby in repserver and switch the users, then disconnect what was the current active (now switched to standby), and just let the transactions of the standby (now active, where users are now working) accumulate in the queues of the repserver.

When you bring the original server back online, the transactions will start coming across, and when your queues go back down to zero, then just switch your users again and switch replication to make the original primary be the primary again.

If you really want to use the dump/load path, yes, you will have to rebuild the warmstandby replication. If your users can be down for the duration of the dump and load then you won't have to rebuild the standby because there won't be any new activity, just rebuild the repserver warmstandby pair.

Regards,

[suznCB]

Thank you very much for replying,

Before you turn off the active ASE to move it, switch active and standby in repserver and switch the users, then disconnect what was the current active (now switched to standby), and just let the transactions of the standby (now active, where users are now working) accumulate in the queues of the repserver.

how can I let transactions of the standby(now active) accumulate in the queues of the repserver, I think this replication is one way ! , how can I be sure that it is bi directions? if it was bi directions, do the transactions return to queues then to (old active) without any configuration? and for this , I should disconnect users from (now active) while I re active the old one, shouldn't I? this is to safe data from conflict.

then as you said: ...and when your queues go back down to zero, then just switch your users again and switch replication to make the original primary be the primary again.

this way safes time more than going with dump and load way, but I just need to be sure there is no possible to conflict data between two databases.