daily migration of Informix 9.4 databases from AIX to RedHat
A user needed to sync several dbspaces nightly between IDS 9.40 on AIX (pSeries) and IDS 9.40 on Red Hat Linux; unload/load was too slow, and HDR, ON-Bar restore and SAN disk snapshots were ruled out because the platforms/processors aren't binary compatible. Suggestions included trigger-based remote updates (criticised as fragile and obsolete), upgrading to UC2, and HPL express unload/load piped over rsh with gzip (requires a quiet source database). Most posters argued Enterprise Replication was the proper answer and that the earlier failure was a setup issue, but the poster rejected ER because frequent table schema changes would force stopping/redefining replicates. No resolution is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi, we are running 2 informix 9.4 instances on two separate machines srv1 AIX p-series server (AIX 5.1) & IDS 9.40.FC1 srv2 intel hardware with redhat linux (8.0) & IDS 9.40.UC1 There are a couple of dbspaces that should be equalized every night. At the moment we are using load/unloads to realize this, but the entire process takes to long to complete during one night ... I considered following options : a) HDR : different OS'ses => not possible b) ER : had a bad experience with this => not an option c) ONBAR backup/restore => not possible because of different OS'ses according to you gurus out there, are there any usefull alternatives ? thanks in advance Stefan
Stefan Voets wrote: >Hi, > >we are running 2 informix 9.4 instances on two separate machines > >srv1 AIX p-series server (AIX 5.1) & IDS 9.40.FC1 >srv2 intel hardware with redhat linux (8.0) & IDS 9.40.UC1 > >There are a couple of dbspaces that should be equalized every night. At the >moment we are using load/unloads to realize this, but the entire process >takes to long to complete during one night ... > >I considered following options : > >a) HDR : different OS'ses => not possible >b) ER : had a bad experience with this => not an option >c) ONBAR backup/restore => not possible because of different OS'ses > >according to you gurus out there, are there any usefull alternatives ? > >thanks in advance > >Stefan > > > > If the volume of transactions is not huge you could consider trigger and update of remote database in realtime mode. Both machines will have to be up all the time. HTH Michael
Stefan Voets <stefan_voets@hotmail.com> wrote:
> Hi,
>
> we are running 2 informix 9.4 instances on two separate machines
>
> srv1 AIX p-series server (AIX 5.1) & IDS 9.40.FC1
> srv2 intel hardware with redhat linux (8.0) & IDS 9.40.UC1
>
> There are a couple of dbspaces that should be equalized every night. At the
> moment we are using load/unloads to realize this, but the entire process
> takes to long to complete during one night ...
>
> I considered following options :
>
> a) HDR : different OS'ses => not possible
> b) ER : had a bad experience with this => not an option
> c) ONBAR backup/restore => not possible because of different OS'ses
>
> according to you gurus out there, are there any usefull alternatives ?
Did you actually try the onbar recovery on Linux?
I could not get onbar to work on Linux (9.40), in 9.30 it did work.
Alternative: perhaps disk snapshots (both servers attached to a SAN).
The theory of operation would be: put srv1 for a moment blocked (onmode -c)
at that time, take a "snapshot" at disklevel (using shared storage, SAN
attached disks), unblock srv1 and then try to bring up srv2.
The disadvantage is that it could be relatively expensive for what you want to
do, but it would be very fast.
Stefan Voets wrote: > > Hi, > > we are running 2 informix 9.4 instances on two separate machines > > srv1 AIX p-series server (AIX 5.1) & IDS 9.40.FC1 > srv2 intel hardware with redhat linux (8.0) & IDS 9.40.UC1 Upgrade to UC2 ASAP. Many features corrected in UC2 > > There are a couple of dbspaces that should be equalized every night. At the > moment we are using load/unloads to realize this, but the entire process > takes to long to complete during one night ... > > I considered following options : > > a) HDR : different OS'ses => not possible > b) ER : had a bad experience with this => not an option just because I am so courious :), details, please ... > c) ONBAR backup/restore => not possible because of different OS'ses > > according to you gurus out there, are there any usefull alternatives ? IMHO best option is ER. But if you have the window and if your DB is not too big, HPL on both sides is maybe an option, too: HPL express mode loading from pipe, which is a rexec/rsh job doing HPL unload on the other machine. Depending on your CPU vs. network speed, gzip on both sides should be considered. dic_k -- Richard Kofler SOLID STATE EDV Dienstleistungen GmbH Vienna/Austria/Europe
Stefan Voets wrote:
>
> srv1 AIX p-series server (AIX 5.1) & IDS 9.40.FC1
> srv2 intel hardware with redhat linux (8.0) & IDS 9.40.UC1
>
> There are a couple of dbspaces that should be equalized every night.
> At the moment we are using load/unloads to realize this, but the
> entire process takes to long to complete during one night ...
>
> I considered following options :
>
> a) HDR : different OS'ses => not possible
> c) ONBAR backup/restore => not possible because of different OS'ses
Both written out principally because the processors are different. Don't
know much about P-series, but I assume they are using the RISC-6000 chip?
Not binary compatible with Intel.
> b) ER : had a bad experience with this => not an option
What bad experience? If it didn't work for you then something was not setup
properly. This is the premier solution I feel. Better to have a post-mortem
about your ER failure and solve it. It can work and does work for many
people in exactly your situation. I can immediately think of a few reasons
that could have killed your previous ER project - all setup issues.
The trigger-and-update suggestion made by someone else is a half-arsed
solution that is worse than ER. If the remote engine goes down, the other
engine's SQLs will fail or at the VERY least the replication will be broken.
Do not consider this option. Sorry Michael - ER was invented precisely to
get away from the problems of trigger based replication, making trigger
based replication obsolete except on sites that, ummm, haven't been
modernised.
ONBAR suggestion: I don't know onbar sufficiently (what have I been DOING?)
but I'd wager the binary compatibility issue would also knock this one down.
Disk snapshots using SAN servers - once again, 6000 and Intel will not
understand each other's data.
HPL pipelined unload could work, but the source database would have to be
totally silent during the process - ie no changes allowed or you'll get
inconsistencies.
Thank you all for the tips, although I still don't feel that ER is the way
to go
why ?
we often have small table changes on the master server (srv1)
so ... when using ER ... we first have to stop the replicate, delete it,
make the modifs on the 2 servers, redefine the replicate & restart it again
people over here don't seem to like this behaviour, nor seem to be able to
adhere to this simple procedure
anyway ... thanks
other suggestions still welcome
"Andrew" <ahamm@mail.com> wrote in message
news:bh9cdd$vttg8$1@ID-79573.news.uni-berlin.de...
> Stefan Voets wrote:
> >
> > srv1 AIX p-series server (AIX 5.1) & IDS 9.40.FC1
> > srv2 intel hardware with redhat linux (8.0) & IDS 9.40.UC1
> >
> > There are a couple of dbspaces that should be equalized every night.
> > At the moment we are using load/unloads to realize this, but the
> > entire process takes to long to complete during one night ...
> >
> > I considered following options :
> >
> > a) HDR : different OS'ses => not possible
> > c) ONBAR backup/restore => not possible because of different OS'ses
>
> Both written out principally because the processors are different. Don't
> know much about P-series, but I assume they are using the RISC-6000 chip?
> Not binary compatible with Intel.
>
> > b) ER : had a bad experience with this => not an option
>
> What bad experience? If it didn't work for you then something was not
setup
> properly. This is the premier solution I feel. Better to have a
post-mortem
> about your ER failure and solve it. It can work and does work for many
> people in exactly your situation. I can immediately think of a few reasons
> that could have killed your previous ER project - all setup issues.
>
> The trigger-and-update suggestion made by someone else is a half-arsed
> solution that is worse than ER. If the remote engine goes down, the other
> engine's SQLs will fail or at the VERY least the replication will be
broken.
> Do not consider this option. Sorry Michael - ER was invented precisely to
> get away from the problems of trigger based replication, making trigger
> based replication obsolete except on sites that, ummm, haven't been
> modernised.
>
> ONBAR suggestion: I don't know onbar sufficiently (what have I been
DOING?)
> but I'd wager the binary compatibility issue would also knock this one
down.
>
> Disk snapshots using SAN servers - once again, 6000 and Intel will not
> understand each other's data.
>
> HPL pipelined unload could work, but the source database would have to be
> totally silent during the process - ie no changes allowed or you'll get
> inconsistencies.
>
>