On-line Package Upgrade using Mirrors, VA's Snapshots...

[Sergio Abrami]

Hi everybody,
does anybody know if it is possible to take advantage of Disk Mirroring or something similar in order to get a Package Upgrade procedure with minimum service interruption and no extra disk required?
We have HP-UX 11i and the SG A.11.14.
Hint: the lvsplit command doesn't work with shared volume groups
Thanks in Advance,
Sergio

[Massimo Bianchi · Accepted solution]

Hi Sergio,
if you mean a change in the cluster software, i see no way to accomplish this.

If you mean something like upgrading an oracle or similar, again no way, because you will have to upgrade the original executables and database after.


You can use mirroring and snapshot to have a fast backup/restore in case of needs, but for further help is better if you specify a little better your intentions...

Massimo

[Steven E. Protter]

You can break the mirrors on the logical volume that the application sits on. Use sam to break it.

It will make a copy called lvolname_copy or something similar.

You can then mount that as a different filesystem, perform the upgrade.

It will take some downtime to switch the logical volumes.

umount the old filesystem

umount the copy filesystem

lvremove or just rename the old logical volume.

rename or simply mount the copy logical volume under the old folder.

Restart your application.

You may have problems with the upgrade due to environment variables. Oracle for example has one called ORACLE_HOME which includes the filesystem name, but these issues are application dependent.

If you are using Service Guard, why not take one of the machines out of the Cluster, perform the upgrade at a leisurely pace, and follow procedures for rejoining the cluster when done.

SEP

[Sergio Abrami]

Thanks Max and SEP!!!

As a matter of fact, I'd like to have a procedure to upgrade an application (executable binaries + a local propietary database) configured as a Service Guard Package. The database can be mounted either on the same or on another logical volume. Regardless any environment variables issues, do you think that SEP's procedure can accomplish this? Are there any database consistency implications?

[Massimo Bianchi]

Hi,
SEP technical hints are perfect, but you will loose any transaction that you will not be able to transfer to the new (patched) DB.

I think that the DB will be consistent, but lacking of the transaction held during the upgrade phase. Unless it is acceptable and sensed to put it in read-only mode before the split.

Massimo

[Steven E. Protter]

Yes Massimo,

My solution should have indicated that the database should be down.

Since the application was not specified, that wasn't a blanket statement I could make.

If you split a mirror on a running Oracle database you are going to have trouble with the data. It can be recovered, depending on how much information was in redo logs, etc.

SEP