Recover checkpoint to server with different locations

[Ingres Forums]

Hi,

We're performing a disaster recovery test and need to recover a
checkpoint from our production server over to our DR box. The issue I
believe I'm having is that the two servers do not have the same INGRES
data locations configured. I think we have the same number of them,
but they're not the same folder paths.

How can I make this happen?

Please note that this DR box has another database within the Ingres
installation that we use, so I need to be careful with changing too much
of the installation.

Thanks,
Kyle


--
kylehanson
------------------------------------------------------------------------
kylehanson's Profile: http://community.actian.com/forum/member.php?userid=113649
View this thread: http://community.actian.com/forum/showthread.php?t=14089

[Karl Schendel]

On Nov 28, 2011, at 1:07 PM, Ingres Forums wrote:

>
> Hi,
>
> We're performing a disaster recovery test and need to recover a
> checkpoint from our production server over to our DR box. The issue I
> believe I'm having is that the two servers do not have the same INGRES
> data locations configured. I think we have the same number of them,
> but they're not the same folder paths.
>
> How can I make this happen?

Andre's suggestion of making a second installation identical to production
is a good one. Or, along the same lines, you could unload the existing
database on the DR box, reinstall Ingres so that it looks identical to the
production installation, and then reload the DR database.

The other options that occur to me at the moment are less good:

You could create symbolic links to match the production installation
paths, pointing to the corresponding DR-installation paths. I can't
offhand think why this wouldn't work, but it would certainly confuse
your sysadmins and future DBA's.

You could grab a copy of the Ingres source and use the structure
definitions found in $ING_SRC/back/dmf/hdr/dm0c.h to write
a little C program that alters the paths in the db-config file(s).
It wouldn't have to be C, I guess. You would have to find and
alter all of the copies of the config file. Marty is apparently
doing something like this, since he's posted recently on the
subject. I actually did something like this in a past life for an
automated DR / warm-backup system, and it can be done,
but it's tricky to get right. I suspect it would be a lot less work to
simply redo your DR ingres installation to match production.

Karl

[Laframboise, André]

Hi,

Maybe consider installing a second Ingres installation on the same server for that database.
You can then make whatever changes you need to get it working without affecting the existing database.
You can also setup the second installation to match the original database configuration which would make the recovery much easier.

Andre

_______________________________________________
Info-Ingres mailing list
Info-...@kettleriverconsulting.com
http://ext-cando.kettleriverconsulting.com/mailman/listinfo/info-ingres

[Martin Bowes]

Hi All,

I would have to agree with Karl's summation.

I would also fully endorse the symlink method, I've used it extensively on UNIX systems and never had a problem. I think there is a reference somewhere in the manual that says its not supported, but I've been told by at least one tech "Yeah and if we stopped supporting symlinks we'd be lynched!". I would also add that as you'll need root privilege to set it up in advance that your systems guys will at least know of it.

As for editing the config file...Down that path lies madness. It can be done, and I can use Perl programs to create a class of editing routines to do the job, but as I've just found out during a recovery that the journal files also contain hardcoded paths used for file creates. I'm still investigating the source of these, but it means that to recover a database using the Config file edit method will also involve a dump/journal file editor as well.

I should point out that the only reason I'm looking at this is that I have been forced into reconsidering this recovery technique by a particularly large database on an old installation that can't be upgraded.

Marty

-----Original Message-----
From: Karl Schendel [mailto:sche...@kbcomputer.com]
Sent: 28 November 2011 20:48
To: Ingres and related product discussion forum
Subject: Re: [Info-Ingres] Recover checkpoint to server with different locations


On Nov 28, 2011, at 1:07 PM, Ingres Forums wrote:

>

> Hi,
>
> We're performing a disaster recovery test and need to recover a
> checkpoint from our production server over to our DR box. The issue I
> believe I'm having is that the two servers do not have the same INGRES
> data locations configured. I think we have the same number of them,
> but they're not the same folder paths.
>
> How can I make this happen?

Andre's suggestion of making a second installation identical to production
is a good one. Or, along the same lines, you could unload the existing
database on the DR box, reinstall Ingres so that it looks identical to the
production installation, and then reload the DR database.

The other options that occur to me at the moment are less good:

You could create symbolic links to match the production installation
paths, pointing to the corresponding DR-installation paths. I can't
offhand think why this wouldn't work, but it would certainly confuse
your sysadmins and future DBA's.

You could grab a copy of the Ingres source and use the structure
definitions found in $ING_SRC/back/dmf/hdr/dm0c.h to write
a little C program that alters the paths in the db-config file(s).
It wouldn't have to be C, I guess. You would have to find and
alter all of the copies of the config file. Marty is apparently
doing something like this, since he's posted recently on the
subject. I actually did something like this in a past life for an
automated DR / warm-backup system, and it can be done,
but it's tricky to get right. I suspect it would be a lot less work to
simply redo your DR ingres installation to match production.

Karl

[Ingres Forums]

Thanks everyone for your replies. It helps confirm the situation that
I figured I'm in, of which is changing locations within a checkpoint is
not really meant to be.

Is there any chance using 'relocatedb --location --newlocation' type
command could help. Here's the overview of what I'm thinking:
- I have a checkpoint from production server I'd like to
recover(it has say 20 data locations all mapped high in folder tree
under /INGRES/ing_prod)
- On the DR box, I've created an empty DB of which I want to
recover this checkpoint.
- This DR box also has about 20 locations but they're all mapped
with a different high folder path of: /opt/IngresII
- Pull over the aaaaaaaa.cnf from the production box to the DR
box
- setup 20 new data locations on DR box to match folder paths
within aaaaaaaa.cnf from production
- use relocatedb -location= -newlocation= to change
aaaaaaaa.cnf to use new locations

I haven't any experience with relocatedb, so I'm hoping it adjusts the
aaaaaaaa.cnf file locations, so maybe your thoughts on this and the
above scenario if it'd get me close to working. I guess if the above
could work, the last laundry item I have is the default data location
because these are different folder paths as well.

New installation definitely sounds the way to go... Thanks again for
your help.

[Ingres Forums]

I'd be very grateful if someone has program source that they'd be
willing to share which reads/allows changes to the aaaaaaaa.cnf file...
Can anyone answer how static this files format is from Ingres version
to version?

[Ingres Forums]

I have a program but it wouldn't help you because it relies on
$II_SYSTEM being the same length.

The files that I change are:
$II_SYSTEM/ingres/dmp/default/mydb/aaaaaaaa.cnf
$II_SYSTEM/ingres/dmp/default/mydb/c*.dmp
$II_SYSTEM/ingres/data/default/mydb/aaaaaaaa.cnf

I had to change the program when we moved from 9.2 to 10.0.

Jeremy


--
jruffer
------------------------------------------------------------------------
jruffer's Profile: http://community.actian.com/forum/member.php?userid=504

[Karl Schendel]

On Nov 29, 2011, at 8:56 AM, Ingres Forums wrote:

>
> I'd be very grateful if someone has program source that they'd be
> willing to share which reads/allows changes to the aaaaaaaa.cnf file...
> Can anyone answer how static this files format is from Ingres version
> to version?

I'm not entirely sure what you have in mind for program source,
but as for your other question ... the cnf file format historically has
a 50/50 chance of changing from version to version (depending
on how you count versions). We're currently on V7 of the cnf file,
the most recent change happening for long ID's in Ingres 10.
The previous cnf file format changes were for version 6, OI 1.x,
Ingres II 2.5, and 2.6. I don't believe that 2.0 or any 9.x had any
cnf format changes.

Karl

[Ingres Forums]

Jeremy,

Would you be willing to share your source code for that program? I
fully understand it doesn't get me where I need to 'today', but at least
it'd be a good starting point if I wanted to further develop it for our
environment...

Much appreciated,

Kyle


--
kylehanson
------------------------------------------------------------------------
kylehanson's Profile: http://community.actian.com/forum/member.php?userid=113649

[Ingres Forums]

Here it is.

Jeremy


+-------------------------------------------------------------------+
|Filename: path_fiddle.txt |
|Download: http://community.actian.com/forum/attachment.php?attachmentid=374|
+-------------------------------------------------------------------+

--
jruffer
------------------------------------------------------------------------
jruffer's Profile: http://community.actian.com/forum/member.php?userid=504

[Ingres Forums]

Thank you very much Jeremy, it is more appreciated than I can express in
words. If I further develop my own future version, I'll be more than
happy to share it with Ingres community.

Thanks again and have a great day,

Kyle


--
kylehanson
------------------------------------------------------------------------
kylehanson's Profile: http://community.actian.com/forum/member.php?userid=113649

[Robert Allely]

I have been watching this discussion - just glad we have the luxury(?) of being able to create the DR installation with the exact same locations as the production installation. We used symbolic links in a previous server but this is much simpler.

Robert

-----Original Message-----
From: info-ingr...@kettleriverconsulting.com [mailto:info-ingr...@kettleriverconsulting.com] On Behalf Of Ingres Forums

Sent: Wednesday, 30 November 2011 4:45 a.m.
To: info-...@kettleriverconsulting.com
Subject: Re: [Info-Ingres] Recover checkpoint to server with different locations

_______________________________________________
Info-Ingres mailing list
Info-...@kettleriverconsulting.com
http://ext-cando.kettleriverconsulting.com/mailman/listinfo/info-ingres

Confidentiality/Privilege Notice:
This communication is confidential and may be legally privileged. If you are not the intended recipient please delete the message and notify the sender at Ports of Auckland Limited. Any use, disclosure, copying, distribution or retention of this communication is strictly prohibited.

[Martin Bowes]

Hi Kyle,

I've never tried the relocatedb style you mentioned...why not give it a try and let us know how you get on.

But it sounds like the symlink option on your DR box is viable. All you need is to get root to do:

mkdir /Ingres
cd /Ingres
ln -s /opt/IngresII ing_prod

Afterwards on your DR box any reference to the production path /Ingres/ingres_prod/ingres/data/default/dbname will actually traverse the equivalent DR path /opt/IngresII/ingres/data/default/dbname

You need to ensure that every location that is used on your prod box has an identical name on your DR box.

So if your prod box has data location names ii_database, ii_database_2, ii_database_3...then these names also exist on your DR box. Ditto for checkpoint, journal, dump work and auxilliary work locations.

Now just create the empty database on the DR host, using the same location names as on the prod host. Checkpoint the database and turn journaling on (assuming its on in the prod version).

You should now be in a position to copy over the config files from the prod host....as a tip ALWAYS save the original DR versions aside before this. Ditto copy in the checkpoint, journal and dump files. The latter include [dc]*.dmp...you need these!

Do an infodb ... check it now looks like the prod version. Check each path mentioned in the output can be accessed.

Do the rollforwarddb

Do alterdb -u... dbname -disable_journaling
then ckpdb +j dbname.

These last two steps are necessary to get the log file on the DR host to play ball. Otherwise you'll find the recovered database marked inconsistent real soon. If the database is too large to want to do a full ckpdb +j, I can show you how to monkey with a cktmpl.def to allow it to do this step without actually taking a backup...just doing the '+j' bit.

Marty

[Ingres Forums]

We've decided to put together a new DR box and create identical folders,
locations, etc... I'm still amazed to this day that I've been working
with Ingres database for 19 years and yet these hard-coded paths have
not found a better solution.