IDS Forum

RE: HDR

Posted By: Madison Pruet
Date: Friday, 14 August 2009, at 4:35 p.m.

In Response To: RE: HDR (mosserp@wellsfargo.com)

Almost right.

With SYNC mode, we don't have to wait until the transaction has been
applied on the secondary, but we do wait until all of the logs of that
transaction have been shipped to the secondary.

=

"mosserp@wellsfar =

go.com" =

<mosserp@wellsfar =
To

go.com> ids@iiug.org =

Sent by: =
cc

ids-bounces@iiug. =

org Subj=
ect

RE: HDR [16690] =

=

08/14/2009 12:57 =

PM =

=

=

Please respond to =

ids@iiug.org =

=

=

> > I'm getting ready to turn on HDR between our production site and ou=
r
> D/R
> > site located 7 miles away. We are running Jenzabar CX on Informix 1=
0
> > and HPUX 11i v2. Our 2 servers are connected via a 20 MB pipe. I've=

> > gone through the documentation but I have some questions below. We
> have
> > a very busy system so I'm trying to avoid little downtime on our
> > production site.
> >
> > 1. We don't want our DR server to take over automatically in any
> > case. If we have a planned shutdown of production, I want to manual=
ly
> > get the D/R site ready. Would I set the DRAUTO parameter in the
> > ONCONFIG file to 0 - Manual? And do I do this on the primary server=

> > only?
>
> No, do this on both servers.
>

<< snipped >>

All good stuff from Art and Madison, of course. I'll just throw in my .=
02
as
someone that has used & admin'ed HDR for about 10 years now.

We run our HDR with asynch. Yes, I know that this *can* be risky,
technically
speaking. But, even with many planned and unplanned failovers, we have
never
lost a transaction (knock, knock), AFAIK. The biggest reason that we us=
e
asynch is that response time is *extremely* critical in this applicatio=
n.
In
synch mode, the data must be committed on the secondary before the comm=
it
is
complete on the primary (Madison, pls correct me if I'm wrong here). Ou=
r
primary and secondary are hundreds of miles apart, with lots of network=

stuff
between them. If a network blip caused an outage of replication, with s=
ynch

mode, it would also hold up txns on the primary, something that the
business
cannot afford. That's our situation, tho -- YMMV. Also, keep in mind th=
at
checkpoints are ALWAYS synch'd -- that is where the primary and seconda=
ry
make
sure that they are in synch, regardless of your DRINTERVAL setting.

To start/stop replication, I always take down the secondary first via
'onmode
-yuck'. Then I switch the primary to standard mode via 'onmode -d
standard'.
When I am ready to restart replication, I first look at which logical l=
og
the
primary is currently at. If the logs have wrapped around since replicat=
ion
was
stopped, such that some of the logs that the secondary would need are n=
ow
only
available via log backups, then I usually just run another level-0 arch=
ive
on
the primary (we use ontape to disk files), do the physical restore (ont=
ape
-p)
of that archive onto the secondary, and then restart replication again =
from

scratch. However, if the logs have *NOT* wrapped, then you can very sim=
ply
restart replication by issuing the 'onmode -d primary
<secondary_dbserver_name>', and then simply bring the secondary server =
back
up
via 'oninit -v'. They will find each other and re-synch automagically.

HTH,
Paul M.

***********************************************************************=
********

Forum Note: Use "Reply" to post a response in the discussion forum.

=

Messages In This Thread

• HDR
  ANDREW PISTOCCHI -- Thursday, 13 August 2009, at 9:46 a.m.
  • Re: HDR
    Art Kagel -- Thursday, 13 August 2009, at 10:18 a.m.
    • RE: HDR
      mosserp@wellsfargo.com -- Friday, 14 August 2009, at 1:57 p.m.
      • RE: HDR
        Madison Pruet -- Friday, 14 August 2009, at 4:35 p.m.
      • Re: RE: HDR
        PETER LANE -- Tuesday, 18 August 2009, at 12:40 p.m.
        • RE: HDR
          mosserp@wellsfargo.com -- Tuesday, 18 August 2009, at 2:07 p.m.
  • Re: HDR
    Madison Pruet -- Thursday, 13 August 2009, at 10:20 a.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.