SEO

--- Madison Pruet <mpruet@comcast.net> wrote:
> Would hetrogenous replication really be a good thing
> to do? Would it help
> drive sales?
>
>
> M.P.
>
>
> ----- Original Message -----
> From: "DL Redden" <redden96@yahoo.com>
> To: "Madison Pruet" <mpruet@comcast.net>;
> <informix-list@iiug.org>
> Sent: Tuesday, April 19, 2005 10:03 AM
> Subject: Re: Replication question...
>
>
> > replication to and possibly from other database
> > platforms (MSSQL, DB2, Oracle). Not an easy task,
> I
> > know, but would be quite helpful in todays IT
> > environment.
> >
> > --- Madison Pruet <mpruet@comcast.net> wrote:
> > > Just a quick question.
> > >
> > > What would be some really cool things for us to
> add
> > > to IDS replication?
> > >
> > >
> > >
> >
>
>
>

Madison,

(Note: All of the following is in the context of HDR)

Cool features are OK (multiple secondarys strikes me as a feature that
would be useful in several situations), but I think that what would
**REALLY** be cool is to make some coding / design changes to make HDR
more "bullet-proof".

We ran into a bad situation last year / earlier this year that was very
detrimental to production: if a big report / query is running on the
secondary, consuming a lot of cpu, memory, and/or disk space, then the
primary can "hang" while trying to replicate to the secondary; it comes
in the form of a very long checkpoint on the primary. Our workaround on
this is to not allow any big queries or reports to be run on the
secondary during peak txn traffic times. :-(

We also ran into another problem this last weekend: After a disconnect
between primary / secondary, just after they got re-connected and were
starting the handshake process, the secondary went back down again.
Normally, this is not a problem, as the primary just gets another "DR:
Cannot connect to secondary server" and everything is OK until the
secondary once again becomes available. This time, tho, when the second
disconnect happened, the primary hung (so much so that I had to do a
kill -9 to bounce it -- Yuck!!).

These are just a couple of examples of some "holes" in HDR. By and
large, I think that HDR is GREAT!! But when we run into situations like
the above, it only encourages those naysayers that keep insisting, "See,
we need to get off of Informix, and switch to another DBMS."

Finally, one other thing: It would be really great if you guys could
come up with a new-and-improved DRAUTO feature for automating switchover
-- one that would not be subject to the pitfalls that plagued the
original DRAUTO. We have implemented a home-grown automated switchover
system, using a special monitoring client that has SSH authority to
execute primary-down and secondary-to-standard scripts on the database
servers, and also to re-route all production clients from primary over
to secondary. Surely you guys can come up with something a lot slicker
than this!!!??? ;-)

BTW, from the limited testing that I have done so far on 9.40 (we are
trying to migrate from 9.30.FC4XC to 9.40.FC6W1, both on HPUX 11), it
looks like HDR *is* getting to be more bullet-proof. Seems to still be
some room for improvement, tho.

HTH,
Paul Mosser

sending to informix-list

mosserp@wellsfargo.com wrote:

> BTW, from the limited testing that I have done so far on 9.40 (we are
> trying to migrate from 9.30.FC4XC to 9.40.FC6W1, both on HPUX 11), it
> looks like HDR *is* getting to be more bullet-proof. Seems to still be
> some room for improvement, tho.

In our experience HDR is a lot better in 9.40 than it was in 9.30 or
7.31. I'm not sure that we've had any issues with it at our 9.40 sites.

Ben.