[Info-Ingres] SAN to SAN replication for Ingres DR
Owen, Damien
-------------------------------------------------------------------------------------------
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.
Grant Croker
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.
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.....
Karl & Betty Schendel
On Jun 24, 2009, at 6:41 AM, Owen, Damien wrote:
> As a DR solution we are trying out SAN to SAN replication.
> Basically all file 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
> transactions and tidy everything up. As long as there are no
> sinister error messages in the errlog assume all is good. Job done!
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.
>
> 2 - Run rollforwarddb for both iidbdb and the application database.
> Since checkpoints and journal files are replicated Ingres has no
> issues rolling both 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 cost is the time it takes to rollforward. Should I place
> more faith in Ingres to be able to recover without the need for
> rollforwarddb or is my paranoia justified?
>
Paranoia is always justified! :-)
Karl
Ingres Forums
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....@barclays.com
------------------------------------------------------------------------
nick....@barclays.com's Profile: http://community.ingres.com/forum/member.php?userid=733
View this thread: http://community.ingres.com/forum/showthread.php?t=10857
Chip Nickolett
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/collaterals/wp/DisasterRecoveryIngres-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.