I am trying to test recovery from a disaster, but feel the SSO part is like a Catch 22 situation. I cannot get it to work.

We have a DB cluster where SSO is also a clustered service, just like the documentation recommends.

I want to be able to recover from a DB/SSO cluster disaster. So the we have a third DB server for log shipping. On that server we also have a “waiting” SSO service to take over as Master. That SSO has joined the current one, but is not Master.

The problem is to make that server the backup server SSO Master.

We cannot run ssomanage -updatedb NewServer.xml if the old DB is down. We cannot ssoconfig -restoresecret secret.bak, since it is not the Master.

Has anyone done this and got it to work?

link|improve this question
Not exactly your case here, but it might shed some light on things for DR; fehlberg.wordpress.com/2010/01/05/… – Bryan Corazza Jun 5 '11 at 12:34
+1 for actually testing disaster recovery plans. – Bart De Vos Jun 21 '11 at 22:09
@TiZon: Thanks :) – Martin Bring Aug 17 '11 at 11:43
feedback

migrated from stackoverflow.com May 24 '11 at 12:02

This question came from our site for professional and enthusiast programmers.

1 Answer

up vote 2 down vote accepted

Problem solved.

One have to point SSO to the new DB before starting the service.

These are the steps to move a SSO master to another server.

Run on the new server:

  1. ssomanage -serverall <New SSO SERVER NAME>
  2. I used SSO Administration GUI to set new DB, but recording to MS you can use ssoconfig -setdb <New DB SERVER NAME> <DATABASE NAME>
  3. ssomanage -updatedb NewServer.xml
  4. Start SSO service
  5. ssoconfig -restoresecret <backup file path>

Voila! Now this SSO is the master.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown

Not the answer you're looking for? Browse other questions tagged or ask your own question.