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

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

-----Original Message-----
From: info-ingres-bounces (AT) kettleriver...ting (DOT) com [mailto:info-ingres-bounces (AT) kettleriverconsulting (DOT) com] On Behalf Of Ingres Forums
Sent: November 28, 2011 1:07 PM
To: info-ingres (AT) kettleriverconsulting (DOT) com
Subject: [Info-Ingres] Recover checkpoint to server with different locations


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


_______________________________________________
Info-Ingres mailing list
Info-Ingres (AT) kettleriverconsulting (DOT) com
http://ext-cando.kettleriverconsulti...fo/info-ingres

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

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

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:schendel (AT) kbcomputer (DOT) 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:

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


_______________________________________________
Info-Ingres mailing list
Info-Ingres (AT) kettleriverconsulting (DOT) com
http://ext-cando.kettleriverconsulti...fo/info-ingres

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.


--
kylehanson

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?


--
kylehanson

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

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

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

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

Here it is.

Jeremy


+-------------------------------------------------------------------+

--
jruffer