Hi Kris,

Chip has this right but now you mention mirrors etc there is more to it.
Rollforwarddb already permits you to rollforward the journals without
recovering the checkpoint by specifying the -c flag. However it is essential
that the database is a state that is consistent with the journals that are
going to be applied. In other words new rows do not exist already, updates
will find the old row in the correct state and deletes will find a row to
delete.

What you seem to be suggesting is that the database files themselves will be
saved using some sort of split mirroring technique and the mirror is mounted
on the standby machine and sync'd up. This is perfectly feasible but
requires bespoke scripting to invoke the utilities that split the mirror and
remount it.
You are likely to get the most reliable results by using an OFFLINE
checkpoint to split the mirror. This is most easily done by writing your
bespoke script and calling it from the ESDD line of the template file. You
would set the WSDD line to : (colon, assuming unix) so that nothing happened
at the location backup stage. ckpdb would be called with +l.
On the rollforward side you can mount the mirror and sync up outside of the
actual rollforwarddb call. You must copy across the journals and the current
config file (aaaaaaaa.cnf) before calling rollforwarddb -c. No changes will
be needed to the template file for that.

If you need to use online checkpoints this gets a little trickier. On the
checkpoint side you can do the same as for an OFFLINE checkpoint. To restore
the checkpoint on the standby machine you will need to copy over the dump
files (as well as the config and journal files). Now you will need to modify
the template file so that the WRDD line does nothing (: colon again) and in
the ERDD line or BRDD line you can mount and sync the mirror. rollfowarddb
is then simply called with the database name parameter and after the sync of
the mirror (mimicking the checkpoint restore) the dump files will be
applied, followed by the journals.

VERY IMPORTANT:
1. Don't modify cktmpl.def directly. Create a copy, change that and use
II_CKPTMP_FILE to point to it.
2. Test, re-test and double re-test this until you have totally validated
that you can recover before you deploy this into live. Remember that you are
changing the backup system for the production database here so you may one
day need to use it for the 'real' database, not just the standby.
3. Document the whole thing thoroughly.
4. Thoroughly re-test this at each new patch and release of Ingres.

Finally the mirroring system you use may demand all sorts of tweaks and
fancy bits to make this works. The odd pause here and there to let things
complete is common place.

Hope that helps.

--
Peter Gale
Comprehensive Solutions International

T: +44 (0)1398 341777 M: +44 (0)7831 513181
PGale (AT) Comp-Soln (DOT) co.uk www.Comp-Soln.co.uk

"Business Savvy. IT Smart" R


-----Original Message-----
From: info-ingres-admin (AT) cariboulake (DOT) com
[mailto:info-ingres-admin (AT) cariboulake (DOT) com] On Behalf Of K A Rickard
Sent: 10 March 2006 16:45
To: Chip Nickolett; info-ingres (AT) cariboulake (DOT) com
Subject: Re: [Info-ingres] Re: dummy checkpoints, rollforwarddb

Thanks Chip,
I guess what I'm more interested in is rolling forward and simply applying
the journal files - not using a checkpoint in it's usual sense. More DR
than hot swap of a backup machine. Basically modifying the cktmpl.def file
so Ingres thinks it has a checkpoint and then restoring from a mirrored
backup , then applying just the journal files.
Any real world experience would be appreciated!
Thanks
Kris

At 01:05 PM 3/9/2006 -0800, Chip Nickolett wrote:
_______________________________________________
Info-ingres mailing list
Info-ingres (AT) cariboulake (DOT) com
http://mailman.cariboulake.com/mailm...py/info-ingres

Peter, are you sure that will work? It's been a few years since I've
done this, but iirc, "rollforwarddb -c" will only work if a rollf +c
has just been done (as indicated by the aaaaaaaa.cnf .

What we had to do was monkey around with the cktmpl.def BRDD line to
keep rollf from removing the data files before applying the journals.
(I admit, I haven't done this on a 2.5+ server -- showing how
out-of-date I am! Has something changed?)

I'm interested in this subject because, by coincidence, I'm in the
process of helping someone out with a DR plan based on an EMC symmetrix
BCV.

Jim

Jim,

You are correct that the database has to have been recovered once from the
checkpoint before you can use -c. But once it has been done you can use -c
as many times as you like providing it is logically correct as far as the
journals are concerned.

The simple way to achieve that would be to run a dummy rollforward with the
WRDD lines set to :. This would set the config file to show a rollforward
had been done even though nothing actually happened. This would need to be
done using an offline checkpoint so that dump files are not applied.

--
Peter
T: +44 (0)1398 341777
PGale (AT) Comp-Soln (DOT) co.uk


-----Original Message-----
From: info-ingres-admin (AT) cariboulake (DOT) com
[mailto:info-ingres-admin (AT) cariboulake (DOT) com] On Behalf Of Jim Gramling
Sent: 10 March 2006 18:55
To: info-ingres (AT) cariboulake (DOT) com
Subject: [Info-ingres] Re: dummy checkpoints, rollforwarddb

Peter, are you sure that will work? It's been a few years since I've
done this, but iirc, "rollforwarddb -c" will only work if a rollf +c
has just been done (as indicated by the aaaaaaaa.cnf .

What we had to do was monkey around with the cktmpl.def BRDD line to
keep rollf from removing the data files before applying the journals.
(I admit, I haven't done this on a 2.5+ server -- showing how
out-of-date I am! Has something changed?)

I'm interested in this subject because, by coincidence, I'm in the
process of helping someone out with a DR plan based on an EMC symmetrix
BCV.

Jim

_______________________________________________
Info-ingres mailing list
Info-ingres (AT) cariboulake (DOT) com
http://mailman.cariboulake.com/mailm...py/info-ingres

Kris (and everyone),

It is very important to fully understand both the checkpoint &
rollforward processes, as well as how Ingres works in general. Having
this understanding allows you to perform simple experiments that
quickly validate whether or not something works. You then need to
repeat the experiment numerous times to ensure that it is consistent
and the results are repeatable. There really are no shortcuts if you
want to ensure that this works as required (and as you have probably
told many people it would work).

We have implemented this type of thing at several companies and on many
systems. Some used mirrors, some just transferred data. Most problems
that I have seen stemmed from an incomplete understanding of how Ingres
works, or taking shortcuts on hardware and then needing to jump through
excessive hoops to make things work. If it is important enough to do
it is probably important enough to do right. Below is an older white
paper that discusses one system we used with mirrors. In that case we
fractured the mirrors, performed a disk copy on the broken mirror, and
then re-mounted the copied disk on the backup (reporting) system.
Everything was consistent on the reporting side as of the time of the
break (midnight for us). The outage on the production side was about 3
minutes. We could then take journals from production and apply them to
reporting if needed.

http://www.comp-soln.com/HA_whitepaper.pdf

BTW, Jason Schmidt has been working on a newer white paper on other HA
clusters that we developed over the past 18 months.

Anyway, I still contend (based on several successful implementations)
that if the systems are configured identically that no other changes
are required to the checkpoint template files. If you do make changes,
do it the way that Peter mentions. Otherwise you will lose your
changes after the next patch or upgrade.

You need to make both systems identical at some point in time. After
that you can simply move the database config file (aaaaaaaa.cnf) and
the journals, run "rollforwarddb -c +j" and the journals will be
recovered. An important caveat here is that unless you have your
complete environment under control it is likely that you will not
always have an identical replica database and will eventually encounter
problems applying journal files. So, either ABSOLUTELY CONTROL
EVERYTHING (table creations & drops (priv & non-priv users),
journaling, rules & procedures, and basically any other schema object)
or DON'T JUST APPLY JOURNALS.

Lots of room for error unless you do things perfectly and validate.

Chip Nickolett (ChipN (AT) Comp-Soln (DOT) com)

US - Comprehensive Solutions - www.Comp-Soln.com
UK - Comprehensive Solutions International, Ltd. - www.Comp-Soln.co.uk