To upgrade an Adaptive Server in a high availability configuration, you must temporarily break the companionship between the primary and secondary companion, and disable monitoring of the Adaptive Server service groups in VCS. You can shutdown or restart either Adaptive Server independently during the upgrade process without triggering unexpected failovers by VCS.
You cannot add, delete, or modify any databases, objects,
users, or logins during the upgrade process. Making these changes
after the companionship is dropped and before it is reestablished
may cause the upgrade to fail or destabilize the cluster by causing
inconsistencies between servers.
Stop the monitoring service and drop companionship
On all nodes in the cluster halt the monitoring service. As root, issue:
hares -modify primary_resource Enabled 0 hares -modify primary_resource Critical 1
If you configured the system for symmetric failover, disable monitoring for the secondary resource:
hares -modify secondary_resource Enabled 0 hares -modify secondary_resource Critical 0 haconf -dump -makero
As root, issue:
hares -offline primary_resource -sys primary_system_name hares -offline secondary_resource -sys secondary_system_name
From the secondary companion, issue:
sp_companion primary_server_name, "drop"
(For symmetric configuration) Drop the secondary’s companionship log in the primary companion and issue:
sp_companion secondary_server_name,"drop"
Ensure that both nodes are in single-server mode:
sp_companion
If the companions are in single-server mode, they return:
Server 'server_name' is not cluster configured. Server 'server_name' is currently in 'Single server' mode.
The servers are now running on their installation node and may be stopped and started independently without the VCS attempting to failover the resources between nodes.
On each node, disable high availability:
sp_configure 'enable HA', 0
Restart Adaptive Server for this change to take effect.
Follow the instructions in the installation guide to upgrade each server.
On all nodes, reenable high availability:
sp_configure 'enable HA', 1
Restart Adaptive Server for this change to take effect.
Ensure that permissions are set correctly for the sybha binary and sybhausers file.
As root, issue these commands from $SYBASE/$SYBASE_ASE/bin:
chown root sybha chgrp sybhagrp sybha chmod 4550 sybha
As root, perfrom these tasks from $SYBASE/$SYBASE_ASE/install:
Ensure that the sybase user is included in the sybhauser file
Issue:
chown root sybhauser chmod 600 sybhauser
Verify:
Changes are properly reflected in the service group and resource properties (for example, Sybase_Home, runserver files, Dataserver_login_file, and so on) in the $SYBASE installation location, or any related files related to high availability in the new installation
You have performed all actions required for establishing companionship described “Preparing Adaptive Server to work with high availability” and "“Configuring the Veritas subsystem for Sybase Failover” and the system maintains these changes after the upgrade is complete.
Reestablishing companionship and resuming resource
monitoring
On each node, manually restart Adaptive Server.
As root from the primary node, restore the monitoring service:
haconf -makerw hares -modify primary_resource Enabled 1 hares -modify primary_resource Critical 1
If you configured the system for symmetric failover, enable monitoring for the secondary resource:
hares -modify secondary_resource Enabled 1 hares -modify secondary_resource Critical 1 haconf -dump -makero
Verify you have performed the prerequisite steps for establishing companionship described in “Configuring companion servers for failover”.
Reestablish companionship between the servers (see “Creating an asymmetric companion configuration” or “Configuring for symmetric configuration”):
dbcc traceon (2209) sp_companion primary_server_name,configure dbcc traceoff(2209)
For symmetric configurations, issue this command on
both companions.
If the secondary server includes user databases, you may see one or more warning messages, which you can safely ignore:
Msg 18739, Level 16, State 1: Server 'server_name', Procedure 'sp_hacmpcfgvrfy', Line 102: Database 'database_name': a user database exists. Drop this database and retry the configuration again.
Restart the Adaptive Server resources on their appropriate nodes. As root on the primary node, enter:
hares -online primary_resource -sys primary_system_name
As root on the secondary node, enter
hares -online secondary_resource -sys secondary_system_name
Run sp_companion to verify that the system is properly configured for symmetric or asymmetric failover.
