The following procedure explains how to upgrade an Adaptive Server configured with high availability. These upgrade steps are applicable only for major upgrades such as 12.5.x to 15.0.x.
Resource groups are used to represent cluster sub-system
entities that contain Adaptive Server storage and network resources
required for Adaptive Server companions in the cluster. For example:
Resource groups are called cluster-packages in HP/MCSG
cluster; and ResourceGroups in Solaris/SunCluster and IBM/HACMP
and Service Groups in VeritasClusterServices for Sun Solaris and
Linux. Similarly, bringing the Resource Group “up” and “down” is
referred to as “online” and “offline” and “enable” and “disable” in
some clusters.
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"
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
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
To complete the change, shut down and restart 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
To complete the change, shut down and restart Adaptive Server.
Run the new Adaptive Server insthasv script against the newly upgraded Adaptive Servers.
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 ASE2.
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
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
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
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.