Upgrading Adaptive Server

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.

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

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).

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.