This chapter provides information about configuring the IRIS FailSafe Sybase database option for use on IRIS FailSafe systems. The major sections in this chapter are as follows:
The required software Sybase failover is as follows:
Sybase database software
See the guide SYBASE SQL Server™ Installation Guide for Silicon Graphics IRIX (Sybase document ID 34080-01-1002-01) for information.
Note: For correct operation of IRIS FailSafe Sybase, the file ctlib.loc must exist in the locales directory for your language. For example, the location of the English file is $SYBASE/locales/us_english/iso_1/ctlib.loc. After installing Sybase and building the SQL Server, ensure that the file for your chosen locale is present; its absense is fatal and difficult to troubleshoot. base IRIS FailSafe software
See the section “Installing the IRIS FailSafe Software” in Chapter 2 of the IRIS FailSafe Administrator's Guide for a complete list of required base software.
IRIS FailSafe Sybase software
The software subsystem is ha_sybs.sw.base.
The subsections below talk about choosing the location of key Sybase files and Sybase databases and the need for customizing certain Sybase files. They also describe a sample configuration of Sybase files and the configuration parameters for this configuration.
In configuring Sybase on an IRIS FailSafe cluster, consider location of these components:
Sybase software ($SYBASE)
Sybase runserver files in their default location, $SYBASE/install/RUN_sqlServerName where the variable sqlServerName is the name of an SQL Server
Sybase databases (including all data files)
All the items above are specified for each Sybase SQL Server. Therefore, you have the flexibility to use different copies of each component, for example Sybase software for each SQL Server (Sybase software for one SQL Server must be identical on both nodes).
To plan an IRIS FailSafe configuration for Sybase, you must answer these questions:
What is the primary node of each SQL Server?
Do all SQL Servers use the same Sybase software or not?
After answering all of the questions above, follow these guidelines for each SQL Server to decide whether to use shared or non-shared disks for each of the Sybase components for that SQL Server:
Sybase software can be on a shared disk or replicated on non-shared disks (it must be identical on each disk).
Sybase runserver files can be on a shared disk or replicated on non-shared disks (the files must be identical on each disk).
Sybase databases must be on one or more XFS filesystems or XLV logical volumes that are on shared disks.
Note: Typically databases are not built on filesystems due to data integrity issues. It is recommended that XLV logical volumes be used as raw devices for your database physical devices.
When configuring highly available SQL Servers, the Sybase runserver files must be located in the $SYBASE/install directory. Their filenames must be of the form RUN_sqlServerName. This is the default name and location used by Sybase—do not customize this pathname.
For a simple Sybase configuration with one SQL Server called SYBASE_11 whose primary node is xfs-ha2, an example configuration is as follows:
| Sybase software |
| |
| Sybase runserver file |
| |
| Sybase Backup Server |
| |
| Sybase database files (master, sybsystemprocs, data) |
|
Table 2-1 lists the label and configuration parameters for the Sybase database in the configuration described in the previous section, “Example Sybase Configuration.”
Table 2-1. Sybase Configuration Parameters
Label or Parameter |
|
|
|---|---|---|
database label | SYBASE_11 | The value is the name of the Sybase SQL Server. |
release-dir | /usr/sybase | The value is the value of $SYBASE. |
master-db-fs | shsybs11 | The value is the label for one (any one) of the filesystems that is used by the database. (See the section “Sybase Blocks” in Chapter 3 for more information.) The server-node of the filesystem's volume must be the primary node of the database. |
backup-server | SYB_BACKUP | The value is the name of the Backup Server. |
FailSafe/Sybase provides two ways of monitoring Sybase servers. Users specify which monitoring method they prefer in the sybase block of the FailSafe configuration file.
If the user specifies monitoring level 1, FailSafe does Sybase server process monitoring. FailSafe/Sybase checks if the specific Sybase server process is running or not. If this method of monitoring is used in conjunction with Sybase shutdown option 3, users are not required to the specify their Sybase user password (sa-passwd) entry in the FailSafe configuration file.
For details about adding information to the FailSafe configuration block, and about the Sybase user password entry and shutdown options, see “Sybase Blocks”.
To specify monitoring level 1, users have to change the Sybase server startup script, $SYBASE/install/RUN_sqlServerName. In the example below, assume this script is /usr/sybase/install/RUN_SYBASE_11. It contains the dataserver command and its options. The -s option to the dataserver command must be specified before the -d option. Also, the -s option argument (Sybase server name) must be in the first 80 characters of the command line. This change is also required if the Sybase shutdown option is set to 3 in the sybase block in the FailSafe configuration file. For example, this command
/usr/sybase/bin/dataserver -d/shsybs -sSYBASE_11 \ -e/usr/sybase/install/errorlog_SYBASE_11 -i/usr/sybase |
must be changed to read:
/usr/sybase/bin/dataserver -sSYBASE_11 -d/shsybs \ -e/usr/sybase/install/errorlog_SYBASE_11 -i/usr/sybase |
If you need more complex monitoring than is provided by the default monitoring stored procedure (see the section “Monitoring Stored Procedure” in Chapter 1) you can create your own monitoring stored procedure. A customized monitoring stored procedure must meet the following requirements:
It must be called sp_failsafe_mon.
It must be installed in the sybsystemprocs database.
It must return a value of 0 if it executed successfully and a value of 1 if it failed.
It must meet a maximum execution time requirement, which is specified by the db-timeout parameter in the sybase block of ha.conf.
For more information on Sybase stored procedures, see the SQL Server Transact-SQL User's Guide (Sybase document ID 32300-01-1000-03).
The procedure for creating a configuration file that includes Sybase configuration information is described below. The procedure assumes that a configuration file that doesn't include Sybase has been created, installed, and tested as described in the IRIS FailSafe Administrator's Guide . Using the procedure, you add information to a copy of the configuration file. Installing the configuration file as /var/ha/ha.conf on both nodes is described in the section “Installing the Configuration File” in this chapter.
Copy the file /var/ha/ha.conf to any directory on one of the nodes in the cluster.
Add all of the volumes that will be used for Sybase to the copy of ha.conf if they are not already specified in ha.conf. Be sure to specify the devname-owner, devname-group, and devname-mode parameters for volumes used as raw devices for Sybase database data. See the sections “Logical Volume Configuration” in Chapter 2 and “Volume Blocks” in Chapter 4 of the IRIS FailSafe Administrator's Guide for more information.
Add all of the filesystems that will be used for Sybase to the copy of ha.conf if they are not already specified in ha.conf. See the section “Filesystem Blocks” in Chapter 4 of the IRIS FailSafe Administrator's Guide for more information.
Append a copy of /var/ha/templates/ha.conf.sybase to the end of the copy of the configuration file.
Complete the block called “application-class sybase.” See the section “Sybase Application-Class Block” in Chapter 3 and the comments in the file for information.
Replicate the “sybase” block so that there is one sybase block for each SQL Server.
Using the configuration parameter choices you made in the section “Planning Sybase Configuration” in this chapter and the information in the section “Sybase Blocks” in Chapter 3, prepare each of the sybase blocks.
Using information in the section “Sybase Blocks” in Chapter 3, prepare the “action sybase” and “action-timer sybase” blocks.
Check the configuration file with the ha_cfgverify command:
# /usr/etc/ha_cfgverify copy_filename
See the section “Verifying the Configuration File” in Chapter 4 of the IRIS FailSafe Administrator's Guide for information about checking configuration with ha_cfgverify.
To install the new version of the configuration file /var/ha/ha.conf on each node, follow the steps described by “Procedure C” in Chapter 7 of the IRIS FailSafe Administrator's Guide .
Follow this procedure to test Sybase configuration and failover:
Comment out all of the Sybase related blocks in /var/ha/ha.conf on one node. Do not comment out the blocks for the filesystems and volumes used for Sybase.
Copy the copy of ha.conf from step 1 to the other node.
Test the failover of the volumes and filesystems that are used by Sybase and are on shared disks using the procedures in “Testing Volumes” and “Testing Filesystems” in Chapter 5 of the IRIS FailSafe Administrator's Guide .
Bring up both nodes in the cluster so that they are running IRIS FailSafe and are in normal state.
Bring up each SQL Server on its primary node using these commands (or the equivalent for your shell):
# su - unix-user # setenv SYBASE release-dir # release-dir/install/startserver -frelease-dir/install/RUN_sqlServerName
Variables unix-user and release-dir are the values of the parameters in ha.conf with these names for the SQL Server you are starting up; sqlServerName is the label for the sybase block in ha.conf for this SQL Server.
(You can identify the primary node of an SQL Server by looking at its master-db-vol or master-db-fs. The volume block for master-db-vol or the volume on which master-db-fs resides lists the server-node for the volume. This is the primary node for the SQL Server.)
Bring up each Backup Server (if any) on its primary node using these commands (or the equivalent for your shell):
# release-dir/install/startserver -frelease-dir/install/RUN_backup-server
backup-server is the values of the parameter in ha.conf with this name for the Backup Server you are starting up.
Check that you can successfully access each of the SQL Servers by entering the isql command for each SQL Server:
# release-dir/bin/isql -U sa-user -P sa-passwd -S sqlServerName
sa-user and sa-passwd are the values of the parameters in ha.conf with these names for the SQL Server you are starting up. sqlServerName is the name of the SQL Server you are starting up and is also the label for the sybase block in ha.conf for this SQL Server. If you get the isql prompt, the SQL Server is accessible.
If you created a custom stored procedure for monitoring (sp_failsafe_mon), test it from isql. At the isql prompt enter:
> use sybsystemprocs > go > sp_failsafe_mon > go (return status = 0)
If the return status is not 0, check whether all the conditions you want to monitor are met. You may need to debug the custom stored procedure and make sure that it returns the appropriate values.
Exit isql by entering:
> exit
Shut down each SQL Server. See the SYBASE SQL Server System Administration Guide (Sybase document ID 32500-01-1000-03) for information on shutting down SQL Servers.
Enter this command on one node to shut down IRIS FailSafe on that node:
# /etc/init.d/failsafe stop
Wait for this command to complete before proceeding.
Enter this command on the other node to shut down IRIS FailSafe on that node:
# /etc/init.d/failsafe stop
Uncomment all of the Sybase blocks in /var/ha/ha.conf on one node.
Copy the copy of ha.conf from step 13 to the other node.
Enter this command on each node to start up IRIS FailSafe:
# /etc/init.d/failsafe start
Verify that each node is in normal state by giving this command on each node:
# /usr/etc/ha_admin -i ha_admin: Node controller state normal
If either node is not in normal state, wait 30 seconds and try the command again.
Check that each of the SQL Server started up by accessing each of the SQL Servers using the isql command you used in step 7.
For the first SQL Server listed in ha.conf (the first sybase block) that has the db-avail parameter set to high, shut down this SQL Server.
Check that IRIS FailSafe fails over all SQL Servers and all other highly available services on the node on which you shut down the SQL Server to the other node. For example, to check for Sybase processes, enter this command:
# ps -ef | egrep sybase sybase 27963 1 0 Jul 12 ? 0:00 /bin/sh /usr/sybase/install/RUN_SYB_BACKUP sybase 27965 27963 0 Jul 12 ? 0:00 /usr/sybase/bin/backupserver -SSYB_BACKUP -e/usr/subase/install/backuplog sybase 27955 27942 0 Jul 12 ? 0:17 /usr/sybase/bin/dataserver -d/usr/sybase/master.dat -sSYBASE_11 -e/usr/subase/install/errorlog sybase 27957 27942 0 Jul 12 ? 0:15 /usr/sybase/bin/dataserver -d/usr/sybase/master.dat -sSYBASE_11 -e/usr/subase/install/errorlog sybase 27959 27942 0 Jul 12 ? 0:19 /usr/sybase/bin/dataserver -d/usr/sybase/master.dat -sSYBASE_11 -e/usr/subase/install/errorlog sybase 27942 1 0 Jul 12 ? 0:00 /bin/sh /usr/sybase/install/RUN_SYBASE_11
The example shows the processes for the SQL Server SYBASE_11 and the Backup Server SYB_BACKUP.
Note: The parent “dataserver” process spawns children to perform asynchronous I/O for the RDBMS instance. These children are also named “dataserver.” Please contact Sybase Technical Support to tune the number of asynchronous I/O threads. Confirm that the node on which you shut down the SQL Server is in standby state:
# /usr/etc/ha_admin -i ha_admin: Node controller state standby
On the node that is now in standby state, enter this command to return it to normal state:
# /usr/etc/ha_admin -rf
Check that the highly available services that failed over in step 19 are stopped on the backup node and restarted on their original node.
For each of the remaining SQL Servers listed in ha.conf whose db-avail parameter is set to high, repeat steps 18 through 22 to verify that they fail over properly when shut down.