HDR and Client Redirection
Joachim Klassen
I currently set up a HDR environment with IDS 10.0 on Suse Linux/Power.
Works like a charm.
Next thing I need to investigate is how to redirect the cleints to the
new primary after a failover. Coming from DB2 I would prefer the method
where I specify the alternate server via DBPATH environment variable at
the client side(looks similar to DB2's client rerouting for me). This
works fine as long as the failed primary is down. But when I
reintegrate the former primary as new standby I run into problems. The
new standby will go online in "Read Only" mode - thus the clients will
connect to him because their INFORMIXSERVER variable still contains its
name.
Am I missing something here or is this works as designed ?
Can I prevent the secondary from being read-only ?
Which method for client redirection do you use out there ?
I searched the docs that I know - but found only 2 chapters in IDS
Admin Guide. Any other docs available ?
TIA for any answer
Joachim
Karl Ostner
you can do it this way:
sqlhosts file:
myServer group - -
myServer1 onsoctcp myHost1 myPort1 g=myServer
myServer2 onsoctcp myHost2 myPort2 g=myServer
setup HDR pair using myServer1 and myServer2.
for your client, set INFORMIXSERVER=myServer
HTH,
Karl Ostner
"Joachim Klassen"
<JoKlassen@email.
com> To
Sent by: inform...@iiug.org
informix-list-bou cc
nc...@iiug.org
Subject
HDR and Client Redirection
03/14/2006 10:19
AM
Hi all,
TIA for any answer
Joachim
_______________________________________________
Informix-list mailing list
Inform...@iiug.org
http://www.iiug.org/mailman/listinfo/informix-list
Obnoxio The Clown
Karl Ostner said:
> Joachim,
>
> you can do it this way:
>
> sqlhosts file:
> myServer group - -
> myServer1 onsoctcp myHost1 myPort1 g=myServer
> myServer2 onsoctcp myHost2 myPort2 g=myServer
>
> setup HDR pair using myServer1 and myServer2.
>
> for your client, set INFORMIXSERVER=myServer
That is documented to work as far as ER is concerned, but TFM does not
explicitly say that it's OK for application use. I would love this to work
for everything, can someone confirm whether it's a documentation issue or
whether it's not supported for application use.
--
Bye now,
Obnoxio
"It's easier with pictures."
-- Cosmo
"But wait, it gets worse."
-- Cosmo
"Run, don't walk, for the nearest exit."
-- Cosmo
Richard Harnden
> Karl Ostner said:
>
>>Joachim,
>>
>>you can do it this way:
>>
>>sqlhosts file:
>>myServer group - -
>>myServer1 onsoctcp myHost1 myPort1 g=myServer
>>myServer2 onsoctcp myHost2 myPort2 g=myServer
>>
>>setup HDR pair using myServer1 and myServer2.
>>
>>for your client, set INFORMIXSERVER=myServer
>
>
> That is documented to work as far as ER is concerned, but TFM does not
> explicitly say that it's OK for application use. I would love this to work
> for everything, can someone confirm whether it's a documentation issue or
> whether it's not supported for application use.
>
No, I can't.
But it seems to work for Art, and I'm sure he has a stricter environment
than most...
"Taking care of Fail Back in HDR"
Art Kagel wrote:
#There is another option. Define a group in the sqlhosts file, much as
#you would from ER, include both servers in the group with the primary
#server listed first. Make the 'e=' entry name the backup server. When
#the primary goes down any application just needs to reconnect when it
#detects the loss of connection, reprepare any statements and redeclare
#cursors and voila! You're back in business.
and:
#OH! Forgot to mention. You would set INFORMIXSERVER or the
#'@servername' clause in a CONNECT TO statement to point to the group
#rather than one of the replicants.
Obnoxio The Clown
So, it's a document omission, then?
Art S. Kagel
> Karl Ostner said:
>
>>Joachim,
>>
>>you can do it this way:
>>
>>sqlhosts file:
>>myServer group - -
>>myServer1 onsoctcp myHost1 myPort1 g=myServer
>>myServer2 onsoctcp myHost2 myPort2 g=myServer
>>
>>setup HDR pair using myServer1 and myServer2.
>>
>>for your client, set INFORMIXSERVER=myServer
>
>
> That is documented to work as far as ER is concerned, but TFM does not
> explicitly say that it's OK for application use. I would love this to work
> for everything, can someone confirm whether it's a documentation issue or
> whether it's not supported for application use.
>
It works in all applications with or without ER running. We began to use
this when DBPATH was broken in CSDK 2.60 or so (forget the release) and have
never wanted to go back. It's much more elegant and the DBAs have control
over the failover cascades. With DBPATH you're at the user's mercy:
User: "The primary server crashed and I can still connect to the database
with dbaccess through the backup server. Why isn't my application connecting?"
DBA: "What's the app?"
User: "We just run flugelhorn.exec!"
DBA: "Hmm, flugelhorn.exec works for me!"
User: "Well it doesn't work out of the cron script that starts it up hourly!"
DBA: "<sigh> What's the name of the cron script?"
User: "NotATrumpet.ksh"
DBA: "The NotATrumpet.ksh script sets DBPATH to the old backup server
explicitely after running the environment setup script. That server was
replaced 5 years ago!"
User: "Well that script's been working fine for 7 years! What did you do to
break it now?"
Art S. Kagel
Art S. Kagel
> Karl Ostner said:
>
>>Joachim,
>>
>>you can do it this way:
>>
>>sqlhosts file:
>>myServer group - -
>>myServer1 onsoctcp myHost1 myPort1 g=myServer
>>myServer2 onsoctcp myHost2 myPort2 g=myServer
>>
>>setup HDR pair using myServer1 and myServer2.
>>
>>for your client, set INFORMIXSERVER=myServer
>
>
> That is documented to work as far as ER is concerned, but TFM does not
> explicitly say that it's OK for application use. I would love this to work
> for everything, can someone confirm whether it's a documentation issue or
> whether it's not supported for application use.
>
It works in all applications with or without ER running. We began to use
Madison Pruet
We changed the behaviou of connecting via the group as part of the ER/HDR
logic that we put into 9.4 so that it would ensure that the 'primary' server
would be the one that we connected to any time that we connected to the
group. Made the change in both client->server connection logic and in
distributed transactions connection logic.
If you want to use this technique, you might also want to consider setting
INFORMIXCONTIME down low as well so that you don't end up waiting too long
on a primary server that isn't there.
M.P.
"Art S. Kagel" <ka...@bloomberg.net> wrote in message
news:441F2D37...@bloomberg.net...
keshav...@gmail.com
into documentation.
cheers,
Keshav.
Nog
very useful to me.