As a DR solution we are trying out SAN to SAN replication. Basically allfile systems used by Ingres sit on a SAN. The production server is running Solaris 10. Using SRDF all of the production file systems are replicated to a SAN in another data centre. Attached to the 2nd SAN is server that is running a Solaris 10 zone (only ever powered up in a DR scenario).

There are no issues starting Ingres up on the DR Solaris zone from the replicated files. The hostname is different so a few quick changes to config.dat are required as well as changes to files in $II_SYSTEM/files/name. Other than that Ingres is more than happy starting up on the new host.

Once Ingres is up and running I see two options.

1 - Trust Ingres and the recovery server to deal with any open transactionsand tidy everything up. As long as there are no sinister error messagesin the errlog assume all is good. Job done!

2 - Run rollforwarddb for both iidbdb and the application database. Sincecheckpoints and journal files are replicated Ingres has no issues rollingboth databases forward.

Being of cautious nature I insisted that option 2 is best as you are far less likely to have any issue with corruption etc... and the only costis the time it takes to rollforward. Should I place more faith in Ingresto be able to recover without the need for rollforwarddb or is my paranoiajustified?

I know the solution depends on how reliable the SAN to SAN replication is, but I have no reason to doubt it from what I've been told by my sys admins. Apparently the replication is never more than 30 seconds behind.

Also the amount of data lost is not really an influencing factor here (5- 10 mins) data loss would be acceptable.

Thanks
Damien Owen


-------------------------------------------------------------------------------------------
This email and the files transmitted with it are meant solely for the use of the individual addressee named above. They may contain confidential and/or legally privileged information. If you are not the addressee or responsible for delivery of the message to the addressee, please delete it from your system and contact the sender right away. Sandyx Systems Ltd has taken steps to ensure that this email and any attachments are virus-free,but it remains your responsibility to confirm and ensure this.

On/El 24/06/09 12:41, Owen, Damien wrote/escribió:
environment variable II_HOSTNAME. The value of this variable will
override the real OS hostname used by Ingres. The command 'iipmhost' is
used by a number of Ingres tools to determine the hostname. It in turn
is a wrapper for the function PMhost() which is used internally in
Ingres/OpenROAD/EA....

For example setting II_HOSTNAME to somemachinename via the shell
environment (for a more permanent change use ingsetenv):

ingres@esva-ubuntu:~$ iipmhost
esva-ubuntu
ingres@esva-ubuntu:~$ ingstop

Ingres/ingstop

Executing ingstop against esva-ubuntu.

Checking for active Ingres processes in installation R3 ...

There is no name server (iigcn) running.
Active name server is required for clean shutdown...

Starting the Name Server...

There is no recovery server (dmfrcp) running.
There are no DBMS servers (iidbms) running.
There are no Net servers (iigcc) running.
There are no Data Access servers (iigcd) running.
There is no archiver process (dmfacp) running.

Shutting down the name server...


ingres@esva-ubuntu:~$ export II_HOSTNAME=somemachinename
ingres@esva-ubuntu:~$ iipmhost
somemachinename
ingres@esva-ubuntu:~$ ingstop

Ingres/ingstop

Executing ingstop against somemachinename.

Checking for active Ingres processes in installation R3 ...

There is no name server (iigcn) running.
Active name server is required for clean shutdown...

Starting the Name Server...

There are no Net servers (iigcc) running.
There are no Data Access servers (iigcd) running.

Shutting down the name server...

regards

grant


--
Grant Croker - Ingres PHP and Ruby maintainer
http://blogs.planetingres.org/grant
If you've never visited or spent time in Santa Fe, New Mexico, then
let me say this: you're a complete idiot. I was myself a complete
idiot till about a year ago.....

On Jun 24, 2009, at 6:41 AM, Owen, Damien wrote:

Unless your SAN replication is strictly order preserving, in that it
replicates updates
in exactly the same order as they occurred on the primary, I wouldn't
rely on this one.

Paranoia is always justified! :-)

Karl

If you go for II_HOSTNAME, and you are using remote database connections
(e.g. Ingres/Net), I would suggest removing/renaming the local ticket
file from $II_SYSTEM/ingres/files/name (probably just
IILTICKET_<II_HOSTNAME>, but you might as well move anything with
'TICKET' in the filename) before restarting Ingres.

These won't always cause an issue, but they can cause a few failed
connections when a database is migrated onto different hardware. If you
are not using II_HOSTNAME, then there is no need to touch these fiiles.


--
nick.bolton (AT) barclays (DOT) com
------------------------------------------------------------------------
nick.bolton (AT) barclays (DOT) com's Profile: http://community.ingres.com/forum/member.php?userid=733
View this thread: http://community.ingres.com/forum/sh...ad.php?t=10857

Damien,

The SAN approach is safe and proven if you take the time to make your
environments "cluster aware." You wouldn't want the DR installation
starting-up and overwriting something in production, nor would you
want an activity performed on the "wrong" installation affecting the
"right" installation (such as a shutdown command). Typical areas to
focus on are: Startup; Shutdown; Accessibility (programs, remote
connections, cron jobs, etc.); and consistency (having identically
configured environments greatly helps this).

I'm a big believer in the value of automation (simple is good,
foolproof is better). Developing wrapper scripts that contain the
"cluster awareness" logic is a great way to do this, and one that I've
used many times on various platforms. You can incorporate simple
tests (like reading a status from a common state file, looking for
processes, testing connections, etc.) in a simple and consistent
manner. That will help you avoid accidents and mistakes. You can
also create simple "sync scripts" to keep the two environments
consistent - something that is very important from a production
support perspective.

A more common issue relating to this type of configuration is
regarding failure and when to failover. There are many causes of
failure, and sometimes you will have a partially functioning system
(hardware, OS, database, whatever - could be caused by a dozen or more
things), so you need to have procedures in place to both determine
when to failover (understanding that there will likely be an unplanned
outage), and then being able to force some event (Ingres shutdown,
disk ownership transfer, floating IP address or hostname, etc.) to
occur. These are non-standard events that need to at least be
identified, and ideally addressed, within the wrapper scripts.

Below are links to two white papers that describe various Ingres
clustering configurations. They might provide tips and insight into
how best to do this.

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

Using rollforwarddb is fine, and good to have as an alternative
recovery path, but it should be unnecessary if using shared disk
devices. If the primary concern is around those shared devices, then
there are products like GoldenGate (www.goldengate.com) and High
Volume Replicator (www.hvr.biz) that perform very efficient
transaction logfile-based replication to keep the environments in sync
on an ongoing basis.

The nice thing is that with modern equipment that is configured with
built-in redundancy, the need to actually use this functionality is
minimized. That doesn't mean that you don't need a DR plan (you
absolutely do - see http://downloads.ingres.com/online/c...gres-WP-CN.pdf
and http://www.comp-soln.com/whitepapers/index.html#dr for free white
papers on business continuity & disaster recovery planning). Using
virtualization via Solaris zones can help with offsite recovery as
well.

Hope this helps. You should have plenty to get you started, but if
you need more hands-on assistance the Ingres Services team can help.

Best regards,

Chip Nickolett - Ingres Corp.