question about mirroring logical logs
Hi,
I have a question about something that I would like to try, and am
wondering
if anyone else has tried it and/or knows for sure if it will work or not.
The goal is to: avoid losing *any* transactions in the logical logs if the
database
disk (a raid) fails. I am using IDS 7.31.
I cannot use ER or HDR to achieve this. That is not an option.
I do onbar nightly, incremental backups of data and transactions logs.
We have, as most sites go, a fairly low transaction rate. So, I have
set the size of the log files fairly small so that they tend to fill
up as fast as possible during the day, between nightly backups, and
thus get backed up by continuous log backup.
However, if the disk fails there will always be some log not yet backed up.
So, I came up with this idea and spoke to IBM Informix IDS Tech Support
today.
One person thought this would work. The other thought that it probably
would
not but was not sure. Can anyone state definitely whether it will or will
not?
Thanks in advance,
Jim Cramer
University of Iowa
The plan:
- use O.S. mirroring (HPUX 11.11 64-bit) to mirror the logical log chunks
to
a separate disk than what the rest of the database is on.
- if the raid with the database fails (it has happened to a couple of our
raids), replace it.
- then use the OS Logical Volume Manager to create LVs of the same size
as what I had on the failed disk.
- bring IDS up empty.
- add the chunks back, with same pathnames (actually symbolic links in
/dev)
as what the crashed instance used.
Recover to the raid logical log chunks the data from all transactions since
the last continuous logical backup to the point in time when the crash
happened:
- using the OS mirroring commands, re-establish the mirror between the
external
disk, containing logical log contents reflecting everything up to the crash,
and then tell the empty half of the logical log mirror, on the raid, to sync
to the
other, external disk, half containing the data.
- do an onbar cold restore, which will try to salvage the logical logs,
which came
from the external mirror disk, and back them up before performing the
restore.
- onbar will then restore the archive and replay the transactions in the
backed up,
salvaged logs which came from the mirror.
One support person felt that it would not work due to some sort of internal
consistency
check failure, probably when trying to replay the salvaged logs. The other
person,
who checked with a 3rd person, thought that it would.
Thanks for reading and for any comments that you have.
Hi,
this might be a dumb question ... :
Why don't you utilize the IDS's built in mirroring ?
- put all your logical log files into a dedicated dbspace,
- use IDS's mirroring to mirror all chunks of that dedicated
dbspace to any disk/device you like ...
This will make recovery much easier, without all this hassle
of OS mirroring, etc.
One additional advice:
There's a file named
$INFORMIXDIR/etc/oncfg_<servername>.<servernum>
It is a small text file, containing some information about
dbspaces, chunks, log files. This info is needed/useful when
looking for log files to be salvaged before a restore.
Create a backup of this file on a regular basis, e.g. when you
are doing your nightly archive ...
(You do not need to backup this "continuously", but I'd recommend
to backup the file after "serious administration changes", e.g. newly
mirroring, adding chunks, dbspaces, log files, etc. The info in the
file is
primarily used to locate things on disks/in chunks, not so much to
determine the state of them. So nightly backup of the file should
suffice ...)
Regards,
Martin
--
Martin Fuerderer
IBM Informix Development Munich
Data Management Solutions
forum.subscriber@iiug.org wrote on 22.04.2004 23:10:06:
> Hi,
> I have a question about something that I would like to try, and am
> wondering
> if anyone else has tried it and/or knows for sure if it will work or
not.
>
> The goal is to: avoid losing *any* transactions in the logical logs if
the
> database
> disk (a raid) fails. I am using IDS 7.31.
>
> I cannot use ER or HDR to achieve this. That is not an option.
>
> I do onbar nightly, incremental backups of data and transactions logs.
> We have, as most sites go, a fairly low transaction rate. So, I have
> set the size of the log files fairly small so that they tend to fill
> up as fast as possible during the day, between nightly backups, and
> thus get backed up by continuous log backup.
> However, if the disk fails there will always be some log not yet backed
up.
>
> So, I came up with this idea and spoke to IBM Informix IDS Tech Support
> today.
> One person thought this would work. The other thought that it probably
> would
> not but was not sure. Can anyone state definitely whether it will or
will
> not?
>
> Thanks in advance,
> Jim Cramer
> University of Iowa
>
> The plan:
> - use O.S. mirroring (HPUX 11.11 64-bit) to mirror the logical log
chunks
> to
> a separate disk than what the rest of the database is on.
>
> - if the raid with the database fails (it has happened to a couple of
our
> raids), replace it.
>
> - then use the OS Logical Volume Manager to create LVs of the same size
> as what I had on the failed disk.
>
> - bring IDS up empty.
>
> - add the chunks back, with same pathnames (actually symbolic links in
> /dev)
> as what the crashed instance used.
>
> Recover to the raid logical log chunks the data from all transactions
since
> the last continuous logical backup to the point in time when the crash
> happened:
>
> - using the OS mirroring commands, re-establish the mirror between the
> external
> disk, containing logical log contents reflecting everything up to the
crash,
> and then tell the empty half of the logical log mirror, on the raid, to
sync
> to the
> other, external disk, half containing the data.
>
> - do an onbar cold restore, which will try to salvage the logical logs,
> which came
> from the external mirror disk, and back them up before performing the
> restore.
>
> - onbar will then restore the archive and replay the transactions in
the
> backed up,
> salvaged logs which came from the mirror.
>
> One support person felt that it would not work due to some sort of
internal
> consistency
> check failure, probably when trying to replay the salvaged logs. The
other
> person,
> who checked with a 3rd person, thought that it would.
>
> Thanks for reading and for any comments that you have.
>
>
>
>
>
>
>
Jim,
Here's my take and suggestions:
OK, so the schene is: all of your dbspaces are on the same structure which is
RAID5 AAAAAAAHHHHHHHH!!!!! NO RAID5! NO RAID5! NO RAID5! NO RAID5!
OK, I'm better now...Had to get that our of my system. I'll comment on the
initial setup later.
But, you want to use a std mirror of the logical log dbspace to another disk
structure which would presumably not crash together with this array. Have I got
that right?
> - using the OS mirroring commands, re-establish the mirror between the
> external
> disk, containing logical log contents reflecting everything up to the crash,
> and then tell the empty half of the logical log mirror, on the raid, to sync
> to the
> other, external disk, half containing the data.
Assuming the mirror is broken, ahh but the primary was part of the crashed
array. OK, I was confused for a sec...
> - do an onbar cold restore, which will try to salvage the logical logs,
> which came
> from the external mirror disk, and back them up before performing the
> restore.
If you just put the logical log dbspace and the root dbspace on a COMPLETELY
separate mirrored pair separate from the main RAID containing the data
dbspaces,
then the whole recovery becomes trivial! Since the rootdb did not crash and
the logs did not crash, when you lose the main array you can just perform a
WARM
restore of the lost dbspaces and the logical logs will be fine! You would only
have a major problem then if both of the mirror drives containing the rootdb
and logical log dbspace were to crash together. As I point out in my NO RAID5
Rant (reposted on CDI just this week!) if you build that mirror from drives
with
different manufacturers lot numbers the probablility of that happening is
vanishingly small!
> - onbar will then restore the archive and replay the transactions in the
> backed up,
> salvaged logs which came from the mirror.
>
> One support person felt that it would not work due to some sort of internal
> consistency
> check failure, probably when trying to replay the salvaged logs. The other
> person,
> who checked with a 3rd person, thought that it would.
>
> Thanks for reading and for any comments that you have.
PLEASE PLEASE go to the CDI archive on the IIUG web site and search for "RAID5
Rant", read my periodic posting, and take it to heart. NO RAID5! NO RAID5!
NO RAID5! NO RAID5! NO RAID5! NO RAID5! NO RAID5! NO RAID5! NO RAID5! NO
RAID5! NO RAID5! NO RAID5! NO RAID5! NO RAID5! NO RAID5! NO RAID5! NO
RAID5! For more ammunition see the BAARF (Battle Against Any RAID Five...) web
site (www.baarf.com). I do not agree with them that RAID3 and RAID4 are as bad
as RAID5, but I do believe that RAID10 is the way to go for ALL arrays and
especially for database systems.
Art S. Kagel
Art S. Kagel