Defining/Redefining a FailSafe Database

Note

  • Before starting this procedure, ensure that you know the full path-name of the clean log partition (directory) on your system.
  • Ensure that Transaction Logging is stopped before you reconfigure.

This procedure must be carried out on both databases in a FailSafe configuration before the FailSafe pair is configured. The following operations are carried out:

Procedure

  1. Select option 1 on the Configuration and Setup menu. A message is then displayed describing the purpose of the procedure and prompting you to confirm that you wish to continue. Enter y.

Configuring Transaction Logging

  1. A menu is then displayed, asking you to select the resilience option that you want to configure:

    Configure database for :
            1. Transaction Handling
            2. Stand-Alone Transaction Logging
            3. Shadow
            4. Failsafe/Heartbeat (UNIX only for Heartbeat)
            5. Stand-Alone Rapid Recovery
            Enter option (1-5) :

    Select option 4 to start the procedure to configure the database for FailSafe operation.

    If Transaction Logging is already configured, the following message prompt is returned:

    Transaction Logging already configured
    Do you want to continue (y/n/q) ? :

    Enter y  to re-define Transaction Logging on the database.

  2. If you are configuring Transaction Logging on a partition database, you are then prompted:

    Do you wish to set up database for Rapid Recovery File System (y/n/q) ?:

    Enter y  to enable Rapid Recovery on this database, or n  if you do not want to configure for Rapid Recovery (refer to Introduction to Rapid Recovery and Configuring Rapid Recovery for more information).

  3. The first prompt is to define/redefine the clean log directory name for the database, as follows:

    Enter full path name of Clean Log directory (log_directory/n):

    Enter the full clean log directory name. Entering n  returns you to the Configuration and Setup menu. If you are re-configuring, any new clean log sub-directory you specify will overwrite the clean log sub-directory entry currently in the database config file.

  4. You are then prompted for the name to be given to the clean log sub-directory to be used by the database.

    OK to make Clean Log subdirectory database_name, (y/n/sub_dir_name):

    Enter a name for the clean log sub-directory, or enter y. Entering y  assigns the default name, shown in the message prompt. Note that the default is the database name.

    If you enter a name instead of accepting the default, then a clean log sub-directory is created with that name and you are prompted to confirm that it is correct.

    OK to make Clean Log subdirectory new_name, (y/n/sub_dir_name) :
  5. If the clean log sub-directory already exists, then you will see the message:

    Clean Log subdirectory sub_dir_name already exists
    Do you want to overwrite it (y/n/q) ? :

    Enter y  to continue the procedure using the selected clean log sub-directory name.

  6. Having set up the configuration parameters, the following message is displayed:

    About to make Clean Log subdirectory database_name
    in Clean Log directory clog _directory_name
    for database database_path
    Is this OK (y/n/q) ? :

    Enter y  to configure Transaction Logging with the parameters shown above.

Configuring FailSafe

  1. With Transaction Logging configured, you can now proceed to configure the database for FailSafe operation. First you are asked whether you want to make the current database the primary or the secondary, with the prompt:

    Is this a primary or secondary database (p/s/n) ? : 

    Enter p  to configure the database as a primary or s  to configure it as a secondary.

    The next sequence of prompts up to step 17 are used to set up the routing of the Transaction Logging link between the two FailSafe machines.

    Note

    On UNIX, when entering the name of a system, this should be the name returned by uname -n. On Windows, it should be the NETBIOS name of the system; that is, the computer name given in the System properties, but omitting the domain name.

    Examples of TCP route names are provided at appropriate prompts. The examples given refer to the FailSafe configuration shown in the diagram below. The names used and their associated IP addresses should be added to the hosts file (/etc/hosts on UNIX or \Windows\System32\drivers\etc\hosts on Windows). Alternatively you can specify the IP addresses.

    Example FailSafe Configuration

    Example FailSafe Configuration

  2. First you are asked for the name of the remote system containing the other FailSafe database:

    Enter remote system name:

    Enter the name of the other (remote) system in the FailSafe pair:

    Enter remote system name: hostb

    Note

    The responses shown as examples in the procedure that follows are for TCP/IP. Windows can only use TCP/IP.

    For Windows, go to step 11.

  3. On a UNIX system you are then prompted:

    Enter preferred route protocol (TCP or RCS) : TCP

    Enter the communications protocol to be used on the dedicated FailSafe logging link; either TCP (Transmission Control Protocol) addressing or RCS (Reality Communication Services). Select TCP unless advised otherwise.

  4. You are then prompted to:

    Enter preferred local route name or hit return if none : hosta.fs
    • On a Windows system, enter the host name (for example, hosta.fs) of the FailSafe LAN controller on the local system.
    • On a UNIX system, if the preferred route protocol is TCP, enter the host name (for example, hosta.fs) of the FailSafe LAN controller on the local system. If the preferred route protocol is RCS, enter the destination entry name in the local ROUTE-FILE which connects to the remote system via the dedicated FailSafe logging link.

    Note

    On Windows, host names on the preferred route must have the form hostName.route (for example, hosta.fs  as shown), where hostName is the same as the name used on the User LAN (fallback route) and route identifies the route. On UNIX, this is preferred, but is not essential.

  5. You are then prompted to:

    Enter preferred remote route name or hit return if none : hostb.fs
    • On a Windows system, enter the host name (for example, hostb.fs) of the FailSafe LAN controller on the remote system.
    • On a UNIX system, if the preferred route protocol is TCP, enter the host name (for example, hostb.fs) of the FailSafe LAN controller on the remote system. If the preferred route protocol is RCS, enter the destination entry name in the remote ROUTE-FILE which connects to the local system via the dedicated FailSafe logging link.

    You are now asked to specify an alternative route to be used if the preferred route fails.

    For Windows, go to step 14.

  6. On a UNIX system, you are prompted to:

    Enter fallback route protocol (TCP or RCS) : TCP

    Enter the communications protocol to be used on the alternative LAN route for the FailSafe logging link (see Use Alternative Failsafe Link). Again, either TCP (Transmission Control Protocol) addressing or RCS (Reality Communication Services). Select TCP unless advised otherwise.

  7. You are then prompted to:

    Enter fallback local route name or hit return if none : hosta
    • On a Windows system, enter the host name of the LAN controller on the local system (for example, hosta) which connects to the alternative LAN for FailSafe logging. This could be the user LAN or a second dedicated FailSafe LAN.
    • On a UNIX system, if the fall-back route protocol is TCP, enter the host name of the LAN controller on the local system (for example, hosta) which connects to the alternative LAN for FailSafe logging; this could be the user LAN or a second dedicated FailSafe LAN. If the fall-back route protocol is RCS, enter the destination entry name in the remote ROUTE-FILE which connects to the local system via the alternative LAN used for FailSafe routing.
  8. You are then prompted to:

    Enter fallback remote route name or hit return if none : hostb
    • On a Windows system, enter the host name of the LAN controller on the remote system (for example, hostb) which connects to the alternative LAN for FailSafe logging. This could be the user LAN or a second dedicated FailSafe LAN.
    • On a UNIX system, if the fall-back route protocol is TCP, enter the host name of the LAN controller on the remote system (for example, hostb) which connects to the alternative LAN for FailSafe logging; this could be the user LAN or a second dedicated FailSafe LAN. If the fall-back route protocol is RCS, enter the destination entry name in the remote ROUTE-FILE which connects to the local system via the alternative LAN used for FailSafe routing.
  9. Next you are asked if you want to enable the Remote Spooling facility. This allows you to spool print jobs from the secondary to the primary and vice versa.

    Note

    If this facility is required, route names for local and remote databases, plus associated Q type entries, must be defined on both systems. Also, in UNIX, USER-FILE entries must exist on both systems for users wishing to use the facility. For information on setting up networking, refer to the User's Reference: Administration.

    You are prompted:

    Do you wish to enable remote spooling (y/n/q) ? :

    If do not want to use remote spooling, answer n  and go to step 17.

    If you answer y, you will be prompted to enter the route names of the local and remote databases. These names are used to allow any spooler operations being performed on the secondary to be routed to the primary spooling subsystem.

    • On a UNIX system, the prompts are:

      Enter local ROUTE-FILE Reality system name or hit return if none : dbasea
      Enter remote ROUTE-FILE Reality system name or hit return if none : dbaseb
    • On a Windows system, you are prompted to:

      Enter local database name or hit return if none : dbasea
      Enter remote database name or hit return if none : dbaseb

    Enter the appropriate names (for example, dbasea  and dbaseb). These names are entered into a parameter (for example, FailsafeSystem=dbasea,dbaseb) in the config file which is used to access the spooler files on the primary database from the secondary.

    A special Q-pointer is then created which points at the SPOOL.JOBS file on the primary database and all accounts are updated with that new Q-pointer. Hence, when FailSafe is active, the Spooler configuration is such that any jobs printed on the primary or secondary are sent to the primary for despooling.

  10. Finally you are asked to:

    Enter full path name of remote database (remote_database/n) :

    Enter the appropriate path name.

  11. A prompt similar to the following is displayed:

    About to configure database "/real0/fs/dbase2"
    as the "Primary" database
    paired with database "/real0/fs/dbase2" on remote host "hostb".
    Is this OK (y/n/q) ? :

    Enter y  to configure the database for FailSafe operation, as specified in the prompt.

  12. You are then asked:

    Do you want to configure the secondary database now (y/n/q)

    Note

    On UNIX, the secondary must be configured for remote administration.

    Enter y  to configure the secondary database. Enter n  to finish the configuration and return to the Configuration and Setup menu.

  13. You are then asked to specify the name of the secondary clean log directory, if different from the primary clean log directory.

    • If this is different from the name entered at step 3, enter the full path name of the secondary clean log directory.
    • If the same as the name entered at step 3, press RETURN.

    When prompted, press RETURN to return to the Configuration and Setup menu.