The following procedure explains how to upgrade an Adaptive Server configured with High Availability. These upgrade steps are only applicable for major upgrades such as 12.5.x to 15.0.2.
Upgrading a High Availability-enabled Adaptive
Server in an active-active configuration:
Drop the high availability companionship.
Asymmetric configuration – on the secondary server, use isql:
sp_companion <primary-server-name>, "drop" go
Symmetric configuration – run the same command as above on both servers.
Use isql to verify that both servers are in single-server mode:
sp_companion go
Use the appropriate command for your cluster system to stop monitoring resources associated with Adaptive Server on each cluster node. You may want to offline or unmanage the resources and resource groups on some cluster systems to prevent unwanted failover during the upgrade.
Log in to the server using isql. Disable HA by entering:
sp_configure 'enable HA', 0 go
To complete the change, shut down and restart the Adaptive Server.
Upgrade each Adaptive Server Enterprise separately, following the instructions in the appropriate upgrade chapter of the installation guide for your platform.
Run the new Adaptive Server Enterprise installmaster script against the newly upgraded Adaptive Servers.
Enable the HA property on the new server. Log in to the server using isql and configure the server to enable HA by entering:
sp_configure 'enable HA', 1 go
To complete the change, shut down and restart the Adaptive Server.
Run the new Adaptive Server installhasvss script against the newly upgraded Adaptive Servers.
Follow the instructions in Using Sybase Failover in a High Availability System to configure the permission and ownership for $SYBASE/$SYBASE_/bin/sybha and $SYBASE/$SYBASE_/install/sybhauser.
Modify high-availability related files such as the RUN_server_file, and the SYBASE.csh and SYBASE.sh files, if those files are required on the cluster platform.
Reconfigure each cluster resource associated with Adaptive Server, depending on platform-specific requirements. For example, on Veritas Cluster, update the HA resource properties, the RUN_server_file, and Sybase_home.
Manually restart Adaptive Server on each cluster node using trace flag 2209. Use the Adaptive Server command line option -T2209.
Use the appropriate command for your cluster system to restart monitoring resources associated with Adaptive Server on each cluster node. You may need to online or manage the resources and resource groups if you offlined or unmanaged them in Step 2.
Reestablish companionship. See Using Sybase Failover in a High Availability System for information on how to configure companionship.
For an asymmetric configuration on the secondary server, use isql:
sp_companion <primary-server-name>, configure go
If user databases exist on the secondary server, you may see one or more warning messages. You can safely ignore these messages, which look similar to:
Msg 18739, Level 16, State 1:
Server 'svr2', Procedure 'sp_hacmpcfgvrfy', Line 102:
Database 'svr2_db1': a user database exists. Drop this
database and retry the configuration again.
For a symmetric configuration run the sp_companion configure command as above on both servers. Use isql to verify that both servers are in single-server mode:
sp_companion go
WARNING! Do not use trace flag 2209 after the Adaptive Server companionship is re-established.
Use the appropriate cluster command to take offline, then bring back online, each resource group associated with Adaptive Server. Make sure you remove the -T2209 option from run_server_file if added. Onlining and offlining the Adaptive Server resource shuts down the server and restarts it using the run_server_file.
Use isql to connect to each Adaptive Server Enterprise and verify the correct server companionship:
sp_companion go
In asymmetric mode, the output you see on the primary server is similar to the following:
Server 'svr1' is alive and cluster configured. Server 'svr1' is configured for HA services. Server 'svr1' is currently in 'Primary normal' mode. (return status = 0)
The output you see on the secondary server is similar to the following:
Server 'svr2' is alive and cluster configured. Server 'svr2' is configured for HA services. Server 'svr2' is currently in 'Secondary normal' mode. (return status = 0)
In symmetric mode, the output you see on the primary server is similar to the following:
Server 'svr1' is alive and cluster configured. Server 'svr1' is configured for HA services. Server 'svr1' is currently in 'Symmetric normal' mode. (return status = 0)
The output you see on the secondary server is similar to the following:
Server 'svr2' is alive and cluster configured. Server 'svr2' is configured for HA services. Server 'svr2' is currently in 'Symmetric normal' mode. (return status = 0)
To verify failover and failback, use the cluster command to switch resources associated with Adaptive Server to another node and then switch back.
Upgrading High Availability-enabled Adaptive Servers
in an active-passive configuration
Use the appropriate cluster system command to take Adaptive Server Enterprise offline.
Use the appropriate cluster system command to stop monitoring resources associated with Adaptive Server Enterprise.
Disable the HA on the server by entering:
sp_configure 'enable HA', 0 go
To complete the change, shut down and restart the Adaptive Server.
Follow the steps in the appropriate upgrade chapter of the installation guide for your platform.
Run the new Adaptive Server installmaster script against the newly upgraded Adaptive Server.
If Adaptive Server is configured for active-passive HA on SunCluster3.x, log in to the server using isql and configure the server to enable HA by entering:
sp_configure 'enable HA', 2 go
If using other cluster systems, make sure ‘enable HA’ is set to 0.
To complete the change, shut down and restart the Adaptive Server.
Modify the high-availability related files such as the RUN_server_file, and the SYBASE.csh and SYBASE.sh files, if those files are required on the cluster platform you are using.
Use the appropriate cluster system command to reconfigure resource properties to reflect the new Adaptive Server installation location.
Manually restart Adaptive Server.
Use the appropriate cluster system command to restart monitoring resource associated with Adaptive Server.
Use the appropriate cluster command to take resources associated with Adaptive Server offline on the same node, then bring them back online.
To verify failover and failback, use the cluster command to switch resources associated with Adaptive Server to another node and then switch back.
