version 11 in plae upgrade and HDR
Tom asked whether the documented v11 in-place upgrade procedure for an HDR pair really requires rebuilding the secondary from a level-0 backup of the migrated primary, or whether the onmode -d commands alone re-sync the pair. Nilesh (IBM) confirmed the secondary must be re-created after migrating the primary; Neil noted this blocks customers with long-distance HDR and huge data. Nick described an unsupported shortcut that worked for him (quiesce and shut down both servers, swap in the new $INFORMIXDIR, start the primary to complete the upgrade, then start the secondary, which caught up via HDR). David suggested an external backup/restore approach using a third mirror at the secondary site, with onmode -c block/unlock and onbar -r -e -p; Neil queried what kind of mirror was meant, and the thread ends without an answer.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Nick Lello describes an explicitly IBM-unsupported procedure to upgrade both sides of a live HDR pair in place (quiesce both engines, shut down primary via 'onmode -yuck' and secondary via 'onmode -yk', swap binaries, restart) specifically to avoid a full level-0 resync over a slow WAN link. He states plainly IBM never sanctioned this; done carelessly on a production HA pair it risks primary/secondary divergence or corruption if internal page/log formats change between releases.
onmode -yuck onmode -yk unsupported in-place HDR pair binary upgrade bypassing documented re-initialization
Advisory only — not a substitute for testing in a non-production environment first.
Hello All
This is a RTFM manual question, I know, but I am going to put this
out there anyway, especially since I think all of our upgrades in the
past have been new hardware migrations and I want to be sure as there
was some doubt in house .
In the v11 Info Center, under "Migrating Clusters to a New Release",
#17 states:
If you have an HDR secondary server:
a. Reestablish the pair on the primary by issuing onmode -d primary
"hdr_secondary_name"
b. Start the HDR secondary server with level 0 restore from level 0
backup that was made on the primary after migration.
c. On the secondary, run onmode -d secondary "primary_server_name" ,
and wait for 'hdr secondary operational' in the message log.
I am reading that this states to completely have the secondary server
redone through the use of a level 0 backup of primary being applied as
a restore on the secondary - correct?
and by stating to reestablish the pair, they just mean to run the
command on primary and then wait for the restore to finish on the
secondary server and then run the next onmode -d.
Thanks
Tom
Tom Lehr wrote:
> Hello All
> This is a RTFM manual question, I know, but I am going to put this
> out there anyway, especially since I think all of our upgrades in the
> past have been new hardware migrations and I want to be sure as there
> was some doubt in house .
>
> In the v11 Info Center, under "Migrating Clusters to a New Release",
> #17 states:
> If you have an HDR secondary server:
> a. Reestablish the pair on the primary by issuing onmode -d primary
> "hdr_secondary_name"
> b. Start the HDR secondary server with level 0 restore from level 0
> backup that was made on the primary after migration.
> c. On the secondary, run onmode -d secondary "primary_server_name" ,
> and wait for 'hdr secondary operational' in the message log.
> I am reading that this states to completely have the secondary server
> redone through the use of a level 0 backup of primary being applied as
> a restore on the secondary - correct?
> and by stating to reestablish the pair, they just mean to run the
> command on primary and then wait for the restore to finish on the
> secondary server and then run the next onmode -d.
RTFM.
--
Cheers,
Obnoxio The Clown
http://obotheclown.blogspot.com
I will now proceed to pleasure myself with this fish.
--
This message has been scanned for viruses and
dangerous content by OpenProtect(http://www.openprotect.com), and is
believed to be clean.
how was the fish?
On Apr 19, 2:27 pm, Obnoxio The Clown <obno...@serendipita.com> wrote:
> Tom Lehr wrote:
> > Hello All
> > This is a RTFM manual question, I know, but I am going to put this
> > out there anyway, especially since I think all of our upgrades in the
> > past have been new hardware migrations and I want to be sure as there
> > was some doubt in house .
>
> > In the v11 Info Center, under "Migrating Clusters to a New Release",
> > #17 states:
> > If you have an HDR secondary server:
> > a. Reestablish the pair on the primary by issuing onmode -d primary
> > "hdr_secondary_name"
> > b. Start the HDR secondary server with level 0 restore from level 0
> > backup that was made on the primary after migration.
> > c. On the secondary, run onmode -d secondary "primary_server_name" ,
> > and wait for 'hdr secondary operational' in the message log.
> > I am reading that this states to completely have the secondary server
> > redone through the use of a level 0 backup of primary being applied as
> > a restore on the secondary - correct?
> > and by stating to reestablish the pair, they just mean to run the
> > command on primary and then wait for the restore to finish on the
> > secondary server and then run the next onmode -d.
>
> RTFM.
>
> --
> Cheers,
> Obnoxio The Clown
>
> http://obotheclown.blogspot.com
> I will now proceed to pleasure myself with this fish.
>
> --
> This message has been scanned for viruses and
> dangerous content by OpenProtect(http://www.openprotect.com), and is
> believed to be clean.- Hide quoted text -
>
> - Show quoted text -
Tom Lehr wrote: > how was the fish? Very pleasurable indeed, thank you! -- Cheers, Obnoxio The Clown http://obotheclown.blogspot.com I will now proceed to pleasure myself with this fish. -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.
That's correct -- after the successful migration of the primary instance,
you need to re-create the HDR secondary instance.
- Nilesh -
informix-list-bounces@iiug.org wrote on 04/19/2010 02:18:39 PM:
> From:,
>
> Tom Lehr <tomcaml@gmail.com>
>
> To:
>
> informix-list@iiug.org
>
> Date:
>
> 04/19/2010 02:20 PM
>
> Subject:
>
> version 11 in plae upgrade and HDR
>
> Sent by:
>
> informix-list-bounces@iiug.org
>
> Hello All
> This is a RTFM manual question, I know, but I am going to put this
> out there anyway, especially since I think all of our upgrades in the
> past have been new hardware migrations and I want to be sure as there
> was some doubt in house .
>
> In the v11 Info Center, under "Migrating Clusters to a New Release",
> #17 states:
> If you have an HDR secondary server:
> a. Reestablish the pair on the primary by issuing onmode -d primary
> "hdr_secondary_name"
> b. Start the HDR secondary server with level 0 restore from level 0
> backup that was made on the primary after migration.
> c. On the secondary, run onmode -d secondary "primary_server_name" ,
> and wait for 'hdr secondary operational' in the message log.
> I am reading that this states to completely have the secondary server
> redone through the use of a level 0 backup of primary being applied as
> a restore on the secondary - correct?
> and by stating to reestablish the pair, they just mean to run the
> command on primary and then wait for the restore to finish on the
> secondary server and then run the next onmode -d.
>
> Thanks
> Tom
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
Thanks Nilesh!
I hear the fish is excellent tongiht.......
On Apr 19, 3:25 pm, Nilesh Ozarkar <nile...@us.ibm.com> wrote:
> That's correct -- after the successful migration of the primary instance,
> you need to re-create the HDR secondary instance.
>
> - Nilesh -
>
> informix-list-boun...@iiug.org wrote on 04/19/2010 02:18:39 PM:
>
>
>
> > From:,
>
> > Tom Lehr <tomc...@gmail.com>
>
> > To:
>
> > informix-l...@iiug.org
>
> > Date:
>
> > 04/19/2010 02:20 PM
>
> > Subject:
>
> > version 11 in plae upgrade and HDR
>
> > Sent by:
>
> > informix-list-boun...@iiug.org
>
> > Hello All
> > This is a RTFM manual question, I know, but I am going to put this
> > out there anyway, especially since I think all of our upgrades in the
> > past have been new hardware migrations and I want to be sure as there
> > was some doubt in house .
>
> > In the v11 Info Center, under "Migrating Clusters to a New Release",
> > #17 states:
> > If you have an HDR secondary server:
> > a. Reestablish the pair on the primary by issuing onmode -d primary
> > "hdr_secondary_name"
> > b. Start the HDR secondary server with level 0 restore from level 0
> > backup that was made on the primary after migration.
> > c. On the secondary, run onmode -d secondary "primary_server_name" ,
> > and wait for 'hdr secondary operational' in the message log.
> > I am reading that this states to completely have the secondary server
> > redone through the use of a level 0 backup of primary being applied as
> > a restore on the secondary - correct?
> > and by stating to reestablish the pair, they just mean to run the
> > command on primary and then wait for the restore to finish on the
> > secondary server and then run the next onmode -d.
>
> > Thanks
> > Tom
> > _______________________________________________
> > Informix-list mailing list
> > Informix-l...@iiug.org
> >http://www.iiug.org/mailman/listinfo/informix-list- Hide quoted text -
>
> - Show quoted text -
>> "Nilesh Ozarkar" <nilesho@us.ibm.com> wrote in message >> news:mailman.137.1271708759.1071.informix-list@iiug.org... That's correct -- after the successful migration of the primary instance, you need to re-create the HDR secondary instance. I can confirm this. It is actually preventing one of our customers from ugrading from 10, as HDR is being run over such a vast distance that it would not be viable to re-establish it now, given the data growth :-(
Thanks Neil I will quiz folks more for other gotchya's at the IIUG conference in KC but for now I am working hard to convince others around me that this is just how the thing is supposed to work and be done, etc. for the in place wiith HDR going from v10 to v11. Some thoughts were that it was as simple as changing primary and then secondary catches up to it to complete the migration but i know the logs don't send that kind of internal information, etc - which is why I am assuming all that re-do is necessary. Tom On Apr 19, 5:21 pm, "Neil Truby" <neil.tr...@ardenta.com> wrote: > >> "Nilesh Ozarkar" <nile...@us.ibm.com> wrote in message > >>news:mailman.137.1271708759.1071.informix-list@iiug.org... > > That's correct -- after the successful migration of the primary instance, > you need to re-create the HDR secondary instance. > > I can confirm this. It is actually preventing one of our customers from > ugrading from 10, as HDR is being run over such a vast distance that it > would not be viable to re-establish it now, given the data growth :-(
This is totally unsupported; but we managed to upgrade from 10.0.fc6 to
11.10.fc1 about 6 months ago in a similar situation (wide-area hdr, database
too big to archive/restore over the network).
Here's what we did:-
- All threads off, take both engines to quiescent mode
- Shutdown primary; onmode -yuck
- Shutdown secondary; onmode -yk
- Get the new Informix software in place on both servers (we have
$INFORMIXDIR pointing to a symbolic link so we can upgrade easily)
- Bring up the primary -- allow all upgrade activity to complete
- Bring up the secondary --- internal upgrade processes + updated pages
spooled through HDR appeared to perform the upgrade cleanly
I'll repeat, IBM in no way sanctioned or supported upgrading the HDR pair in
this manner; we did this out of desperation to get the upgrade completed.
On 19 April 2010 23:57, Tom Lehr <tomcaml@gmail.com> wrote:
> Thanks Neil
> I will quiz folks more for other gotchya's at the IIUG conference in
> KC
> but for now I am working hard to convince others around me that this
> is just how the thing is supposed to work and be done, etc.
> for the in place wiith HDR going from v10 to v11.
> Some thoughts were that it was as simple as changing primary and then
> secondary catches up to it
> to complete the migration
> but i know the logs don't send that kind of internal information, etc
> - which is why I am assuming all that re-do is necessary.
> Tom
>
>
> On Apr 19, 5:21 pm, "Neil Truby" <neil.tr...@ardenta.com> wrote:
> > >> "Nilesh Ozarkar" <nile...@us.ibm.com> wrote in message
> > >>news:mailman.137.1271708759.1071.informix-list@iiug.org...
> >
> > That's correct -- after the successful migration of the primary instance,
> > you need to re-create the HDR secondary instance.
> >
> > I can confirm this. It is actually preventing one of our customers from
> > ugrading from 10, as HDR is being run over such a vast distance that it
> > would not be viable to re-establish it now, given the data growth :-(
>
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
>
--
Nick Lello | Web Architect
o +44 (0) 20 7170 5200 | d +44 (0) 20 7170 5215 | m +44 (0) 7917 138319 |
nick.lello@rentrak.com
RENTRAK EDI | www.rentrak.com | NASDAQ: RENT
Notice: On 29th January 2010, Rentrak Corporation acquired Nielsen EDI and,
as such, this message may be delivered via Rentrak or Nielsen message
systems. This message is confidential and is intended only for the
recipient(s) named above. If you have received this message in error, or are
not the named recipient(s), please immediately notify the sender and delete
this message.
thanks nick
that's very interesting as that is what some folks were talking about
doing for us here
but i could see how if things did not go well for the migration, they
may not go well when contacting support either,
which i imagine would result in a complete tear down and re-build of
everything.
i am assuming from your post that you have not seen any glitches,
weirdness, etc since you have upgraded.
Tom
On Apr 20, 2:43 am, Nick Lello <nick.le...@rentrakmail.com> wrote:
> This is totally unsupported; but we managed to upgrade from 10.0.fc6 to
> 11.10.fc1 about 6 months ago in a similar situation (wide-area hdr, database
> too big to archive/restore over the network).
>
> Here's what we did:-
>
> - All threads off, take both engines to quiescent mode
> - Shutdown primary; onmode -yuck
> - Shutdown secondary; onmode -yk
> - Get the new Informix software in place on both servers (we have
> $INFORMIXDIR pointing to a symbolic link so we can upgrade easily)
> - Bring up the primary -- allow all upgrade activity to complete
> - Bring up the secondary --- internal upgrade processes + updated pages
> spooled through HDR appeared to perform the upgrade cleanly
>
> I'll repeat, IBM in no way sanctioned or supported upgrading the HDR pair in
> this manner; we did this out of desperation to get the upgrade completed.
>
> On 19 April 2010 23:57, Tom Lehr <tomc...@gmail.com> wrote:
>
>
>
>
>
> > Thanks Neil
> > I will quiz folks more for other gotchya's at the IIUG conference in
> > KC
> > but for now I am working hard to convince others around me that this
> > is just how the thing is supposed to work and be done, etc.
> > for the in place wiith HDR going from v10 to v11.
> > Some thoughts were that it was as simple as changing primary and then
> > secondary catches up to it
> > to complete the migration
> > but i know the logs don't send that kind of internal information, etc
> > - which is why I am assuming all that re-do is necessary.
> > Tom
>
> > On Apr 19, 5:21 pm, "Neil Truby" <neil.tr...@ardenta.com> wrote:
> > > >> "Nilesh Ozarkar" <nile...@us.ibm.com> wrote in message
> > > >>news:mailman.137.1271708759.1071.informix-list@iiug.org...
>
> > > That's correct -- after the successful migration of the primary instance,
> > > you need to re-create the HDR secondary instance.
>
> > > I can confirm this. It is actually preventing one of our customers from
> > > ugrading from 10, as HDR is being run over such a vast distance that it
> > > would not be viable to re-establish it now, given the data growth :-(
>
> > _______________________________________________
> > Informix-list mailing list
> > Informix-l...@iiug.org
> >http://www.iiug.org/mailman/listinfo/informix-list
>
> --
>
> Nick Lello | Web Architect
> o +44 (0) 20 7170 5200 +44 (0) 20 7170 5200| d +44 (0) 20 7170 5215 +44 (0) 20 7170 5215| m +44 (0) 7917 138319 +44 (0) 7917 138319|
> nick.le...@rentrak.com
> RENTRAK EDI |www.rentrak.com| NASDAQ: RENT
>
> Notice: On 29th January 2010, Rentrak Corporation acquired Nielsen EDI and,
> as such, this message may be delivered via Rentrak or Nielsen message
> systems. This message is confidential and is intended only for the
> recipient(s) named above. If you have received this message in error, or are
> not the named recipient(s), please immediately notify the sender and delete
> this message.- Hide quoted text -
>
> - Show quoted text -
"Nick Lello" <nick.lello@rentrakmail.com> wrote in message
news:mailman.140.1271749880.1071.informix-list@iiug.org...
This is totally unsupported; but we managed to upgrade from 10.0.fc6 to
11.10.fc1 about 6 months ago in a similar situation (wide-area hdr, database
too big to archive/restore over the network).
>> Here's what we did:-
All threads off, take both engines to quiescent mode
Shutdown primary; onmode -yuck
Shutdown secondary; onmode -yk
Get the new Informix software in place on both servers (we have $INFORMIXDIR
pointing to a symbolic link so we can upgrade easily)
Bring up the primary -- allow all upgrade activity to complete
Bring up the secondary --- internal upgrade processes + updated pages
spooled through HDR appeared to perform the upgrade cleanly
>> I'll repeat, IBM in no way sanctioned or supported upgrading the HDR pair
>> in this manner; we did this out of desperation to get the upgrade
>> completed.
That's interesting. In depsperation, we might need to do this too ...
On 20 Apr, 14:13, "Neil Truby" <neil.tr...@ardenta.com> wrote:
> "Nick Lello" <nick.le...@rentrakmail.com> wrote in message
>
> news:mailman.140.1271749880.1071.informix-list@iiug.org...
> This is totally unsupported; but we managed to upgrade from 10.0.fc6 to
> 11.10.fc1 about 6 months ago in a similar situation (wide-area hdr, database
> too big to archive/restore over the network).
>
> >> Here's what we did:-
>
> All threads off, take both engines to quiescent mode
> Shutdown primary; onmode -yuck
> Shutdown secondary; onmode -yk
> Get the new Informix software in place on both servers (we have $INFORMIXDIR
> pointing to a symbolic link so we can upgrade easily)
> Bring up the primary -- allow all upgrade activity to complete
> Bring up the secondary --- internal upgrade processes + updated pages
> spooled through HDR appeared to perform the upgrade cleanly
>
> >> I'll repeat, IBM in no way sanctioned or supported upgrading the HDR pair
> >> in this manner; we did this out of desperation to get the upgrade
> >> completed.
>
> That's interesting. In depsperation, we might need to do this too ...
This should be even easier using external backup and restore to
initiate HDR.
http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.bar.doc/barmst184.htm
1. Create a third mirror for the primary at the secondary site (resync
might take several days - fine)
2. Convert source (primary) server back to standard server (onmode -d
standard)
3. Shutdown target (secondary) server.
4. Upgrade source server as normal (mirror sends changes to target
site).
5.- onmode -c block on primary
6. Detach third mirror on secondary site (boom, instance backup)
7. onmode -c unlock on primary
8. Make primary a primary server again onmode -d primary
<secondary name>
9. On target server flip links point to the third mirror of the source
server (boom instance restore)
10. On target server do external restore (onbar -r -e -p)
11. Make target server a secondary again (onmode -d secondary <primary
servername>
12. If logs for resync are not automatically picked up off the
primary disk then logically restore secondary (onbar -r -l)
<david@smooth1.co.uk> wrote in message
news:21f17bed-0c3a-4311-a7d5-ec3a0f09acdc@g30g2000yqc.googlegroups.com...
On 20 Apr, 14:13, "Neil Truby" <neil.tr...@ardenta.com> wrote:
> "Nick Lello" <nick.le...@rentrakmail.com> wrote in message
>
> news:mailman.140.1271749880.1071.informix-list@iiug.org...
> This is totally unsupported; but we managed to upgrade from 10.0.fc6 to
> 11.10.fc1 about 6 months ago in a similar situation (wide-area hdr,
> database
> too big to archive/restore over the network).
>
> >> Here's what we did:-
>
> All threads off, take both engines to quiescent mode
> Shutdown primary; onmode -yuck
> Shutdown secondary; onmode -yk
> Get the new Informix software in place on both servers (we have
> $INFORMIXDIR
> pointing to a symbolic link so we can upgrade easily)
> Bring up the primary -- allow all upgrade activity to complete
> Bring up the secondary --- internal upgrade processes + updated pages
> spooled through HDR appeared to perform the upgrade cleanly
>
> >> I'll repeat, IBM in no way sanctioned or supported upgrading the HDR
> >> pair
> >> in this manner; we did this out of desperation to get the upgrade
> >> completed.
>
> That's interesting. In depsperation, we might need to do this too ...
This should be even easier using external backup and restore to
initiate HDR.
http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.bar.doc/barmst184.htm
>> 1. Create a third mirror for the primary at the secondary site (resync
might take several days - fine)
What kind of a mirror? A SAN replication mirror (in our case, replicating
via 2Mbs IP from London to Sydney)?
Or, am I misunderstanding (probably!) ...?
thanks