Notes:
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:
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.
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).
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.
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) :
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.
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.
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
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.
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.
You are then prompted to:
Enter preferred local route name or hit return if none : hosta.fs
hosta.fs
) of the FailSafe LAN
controller on the local system.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.
You are then prompted to:
Enter preferred remote route name or hit return if none : hostb.fs
hostb.fs
) of the FailSafe LAN
controller on the remote system.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.
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.
You are then prompted to:
Enter fallback local route name or hit return if none : hosta
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.You are then prompted to:
Enter fallback remote route name or hit return if none : hostb
hostb
)
which connects to the alternative LAN for FailSafe logging. This could be the
user LAN or a second dedicated FailSafe LAN.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.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.
Finally you are asked to:
Enter full path name of remote database (remote_database/n) :
Enter the appropriate path name.
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.
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.
You are then asked to specify the name of the secondary clean log directory, if different from the primary clean log directory.
When prompted, press RETURN to return to the Configuration and Setup menu.