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 Resource Groups. You can shutdown or restart either Adaptive Server independently during the upgrade process without triggering unexpected failovers by the SunCluster subsystem.
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.
Stopping the monitoring service and dropping companionship
Halt the monitoring service and stop management for the Adaptive Server resource groups on all nodes in the cluster. As root, issue:
scswitch -F -g primary_resourcegroup_name scswitch -u -g secondary_resourcegroup_name
From the secondary companion, issue:
sp_companion primary_server_name, "drop"
(For symmetric configuration) Drop the secondary’s companionship. Log in to the primary companion and issue:
sp_companion secondary_server_name,"drop"
Ensure that both nodes are in single-server mode by issuing on each node:
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 cluster 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.
Alternatively, if the companions are shut down, you
can edit their server configuration files (server_name.cfg),
changing the value of enable HA to zero
Follow the instructions in the installation guide to upgrade each server.
On each node, reenable high availability:
sp_configure 'enable HA', 1
Restart Adaptive Server for the change to take effect. See the Configuration Guide.
On the upgraded servers, reinstall the scripts (installmaster, installhasvss, installsecurity, and so on). See “Reinstalling installmaster” and “Rerunning installhasvss”. When you reinstall installmaster, you must reinstall installhasvss.
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 resource 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 for active-active setup” and "“Configuring the Sun Cluster subsystem” and the system maintains these changes after the upgrade is complete.
The following files exist and have correct information:
$SYBASE/$SYBASE_ASE/SC-3_0/etc/hacompanion.server_name
$SYBASE/$SYBASE_ASE/SC-3_0/etc/ase_login_file
Reestablishing companionship and resuming resource
monitoring
On each mode, manually restart Adaptive Server.
As root, issue this command to restore the monitoring service:
scswitch -z -g primary_resourcegroup_name -h primary_node scswitch -z -g secondary_resourcegroup_name -h secondary_node
Verify both the resource groups and the Adaptive Server resources are online on their nodes with the scstat -g command (see your Sun documentation).
Log in to the primary and secondary companions with isql to verify both are running.
Select SunCluster3.x as the high availability library (see“High availability services library within Adaptive Server”).
Reestablish companionship between the servers (see “Creating an asymmetric companion configuration” or “Setting up a 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.
Run sp_companion to verify that the system is properly configured for symmetric or asymmetric configuration.
Failover the primary companion by relocating the associated resource group to secondary node. As root:
scswitch -z -g primary_resourcegroup_name -h secondary_node
Log in to the secondary companion and issue sp_companion to verify the failover successfully completed.
Failback the Adaptive Server by following instructions in section “Failing back to the primary companion”.
Log in to the primary and secondary companions and issue sp_companion to verify the failover successfully completed.