SEO

> -----Original Message-----
> From: owner-informix-list@iiug.org
> [mailtowner-informix-list@iiug.org] On Behalf Of mpruet@comcast.net
> Sent: Wednesday, February 11, 2004 5:14 PM
> To: informix-list@iiug.org
> Subject: ER and HA environment questions
>
>
> I'd like to start a separate thread on this issue.
>
> Based on the feature request thread, there were some folks requesting
> better functionality of ER in an HA solution. I'd like some feedback
> on that.
>
> 1) Why is ER being used for HA instead of HDR?
>
> 2) What specific functionality is being requested on ER?
>
>
> I realize that quite a few folks prefer usage of ER over HDR because
> the secondary server can be more than a read-only server, a sub-set of
> the main server, or on a different platform. However, HDR will always
> be much easier to set up and ER does not support a synchronous mode of
> replication.
>
> But I would like to get a bit of feedback on this topic so I can
> better understand why ER is being used and what the perceived pain
> points are with HDR.
>
> Thanks
> M.P.
>

We have been using HDR here for a highly critical, high txn-volume app for
several years now. HA is extremely important, no regular maintenance
window. Since we are on 9.30 (9.30.FC4XC, to be exact), DRAUTO is not an
option for us. Primary and secondary are hundreds of miles apart, so HP
ServiceGuard or similar is not possible. When we *do* have to failover to
secondary, we:
-- *try* to cleanly disconnect all client connections (this is not always
possible);
-- put primary to quiescent, roll the logs a couple of times, force
checkpoint, switch mode to "standard", bring down primary;
-- bounce secondary, switch it to "standard" mode, wait for logical recovery
to complete, bring it from quiescent to online;
-- move the client connections to the secondary

All of this requires an outage of 5 to 10 minutes. Planned outages (schema
changes, etc.) are handled in basically the same way. Outage times for
unplanned outages can increase due to problem investigation, decision time,
etc. -- but that is a procedural problem.

What management is now looking for is an environment where the client
connections can be automatically and *seamlessly* (i.e., no outage) switched
over to the secondary whenever a problem is detected. The problem detection
mechanism and the client switching mechanism are being worked separately
from the database issue. But that "automatic switching" scenario demands
that the secondary server be ready to take *update* traffic without having
to go thru the failover procedure outlined above.

ER is currently being looked at as a possible HA solution. The major
obstacle is, of course, schema changes (2 - 4 per year). Plus the fact that
this is a very high txn-volume environment.

On the surface, using HDR with DRAUTO enabled might help, but I understand
the reasons that DRAUTO was discontinued. Maybe the problems with DRAUTO
should be re-visited and *solved*, rather than the feature simply being
discontinued.

Personally, I like the simplicity and robustness of HDR over the complexity
and overhead of ER (no offense!), and would rather see an HDR solution to
our business problem. But it is looking like ER in "update anywhere" mode
is our most logical option at this point. (Note: Initially, all clients
will be connected to only one server at a time; eventually, they want to
move to true update anywhere with connections to both servers.).

Suggestions??

TIA,
Paul Mosser
sending to informix-list


sending to informix-list