(a) Information needed in the primary and secondary systems

Make sure that the following information is the same in both the primary and secondary systems:

• Versions of HiRDB and related programs
• HiRDB administrator's environment (user ID, group ID, and environment variables)
• Absolute path names of the HiRDB directories
• HiRDB system definitions
• HiRDB file definition formats
• User-executable programs

(b) Notes concerning environment settings

• Set up the HiRDB environment in both the primary system and the secondary system, and use the same version of HiRDB in both. When you upgrade HiRDB, also make sure that you upgrade both the primary system and the secondary system.
• Do not create the HiRDB directory on a shared disk.
• If you are not using a DNS server, register a re-allocatable IP address in the hosts file.
• Install the following product and set up the environment:
  
  • HA Toolkit Extension (for the primary and secondary system machines). Note that this installation is not necessary when the cluster software product being used is HA Monitor.
• The system switchover facility is not applicable to a recovery-unnecessary front-end server unit.
• When you are applying a multi-standby configuration, you must enable the multi-standby facility of the cluster software product you are using. For details about how to set up a multi-standby facility, see the documentation for the applicable cluster software product.

There must be an external hard disk that can be shared between the primary system and the secondary system. This hard disk is called a shared disk unit.

(a) Shared disk allocation

The following figure shows shared disk allocation.

Figure 26-61 Shared disk allocation

Explanation

A shared disk is allocated to each unit because system switchovers occur on a unit-by-unit basis.

Create the following HiRDB file system areas on the shared disk unit:

• HiRDB file system area for RDAREAs
• HiRDB file system area for system files
• HiRDB file system area for backup files
• HiRDB file system area for unload log files

Notes

• Set up these HiRDB file system areas so that the HiRDBs of both the primary system and the secondary system can reference the shared disk unit by using the same path name.
• The shared disk on which HiRDB file system areas for shared RDAREAs are created must be activated in the write mode from all units. For this reason, the disk must not be deactivated or activated in conjunction with a system switchover.
• On a shared disk, use character special files instead of regular files. If a system switchover occurs when regular files are in a status that does not apply to shared disks (for example, data remains in the operating system cache even though HiRDB finished writing it to the target files), any updates made to the files might be lost. Note that if the operating system can guarantee the integrity of the data in regular files (journal file systems) even if a system switchover occurs, the following files can be used on a shared disk:
  Unload log files that are unloaded using the pdlogunld command or the automatic log unloading facility
  Backup files that are acquired using the database copy utility (pdcopy)
  Unload data files that are created using the database reorganization utility (pdrorg)
  

(b) Shared disk access control

If the system switchover source and target both attempt to access the shared disk at the same time while the system switchover facility is being used, the database might become corrupted. For this reason, accesses from the system to the shared disk must be controlled. Shared disk access control is performed by the cluster software or HiRDB.

Normally, the method described in Shared disk access control by the cluster software is used to perform access control on the shared disk. To use the method described in Shared disk access control by HiRDB, you must have HA Monitor 01-08 or later.

Shared disk access control by cluster software

The cluster software performs access control on the shared disk. It exercises control in such a manner that the running system is active and the standby and stopped systems are inactive, so that only the running system can access the shared disk. The following figure shows shared disk access control by the cluster software.

Figure 26-62 Shared disk access control by the cluster software

Explanation

An inactive system cannot access the shared disk. Only the running system can access the shared disk.

For details about the shared disk switching method (between active and inactive), see the cluster software documentation.

If you are using HA Monitor, you must specify the disk operand in the servers definition statement for HA Monitor.

Shared disk access control by HiRDB

To use HiRDB to perform access control on the shared disk, you must have HA Monitor 01-08 or later.

HiRDB can perform access control on the shared disk. In this case, shared disk switching (between active and inactive) is not performed. System switchovers take place in the following sequence:

1. A failure that triggers a system switchover occurs.
2. HiRDB confirms that all processes (HiRDB processes) have terminated in the source system.
3. The system switchover takes place.
4. The target system starts accessing the shared disk.

The following figure shows the shared disk access control that is provided by HiRDB.

Figure 26-63 Shared disk access control by HiRDB

• Criteria
  Use HiRDB to perform shared disk access control in the following cases:
  
  • When Linux is being used
    Character special files on an LVM are not supported in the Linux edition, but an LVM is required by a shared disk whose access is to be controlled by HA Monitor. For this reason, you cannot use the method described in Shared disk access control by the cluster software.
    If Linux AS 4 or Linux ES 4 or later is used, character special files on an LVM can be used, which allows cluster software to be used to control access to the shared disk.
    
  • When shared RDAREAs are used
    When shared RDAREAs are used, the shared disk that contains a shared RDAREA must be made active from all server machines where a back-end server is located. If an updatable back-end server and a reference-only back-end server are both located on the same server machine, the updatable back-end server becomes the target of any system switchover that occurs. If shared disk switching occurs in such a case, the shared RDAREA can no longer be referenced from the reference-only back-end server. Therefore, you cannot use the method described in Shared disk access control by the cluster software.
    
  • When Real Time SAN Replication is used in the log-only synchronous method
    When Real Time SAN Replication is used in the log-only synchronous method, TrueCopy is used at the log application site to copy system files from a remote location. When TrueCopy is used, LVM cannot be used, but LVM is required for a shared disk whose access is to be controlled by HA Monitor. For this reason, you cannot use the method described in Shared disk access control by the cluster software.
    
• HiRDB environment settings
  Specify the following operands in the HiRDB system definition:
  
  • pd_ha_prc_cleanup_check = Y
    When Y is specified in this operand, system switchovers take place only after all processes have terminated in the unit.
    
  • pd_ha_switch_timeout = Y
    At times, a system switchover cannot be performed because, due to ongoing disk I/O processing or some other reason, a server process has not terminated. When Y is specified in this operand, HA Monitor treats it as a server (HiRDB) slowdown and resets the system, so that the system switchover can take place.
    
• HA Monitor environment settings
  Specify operands in the servers definition statement for HA Monitor as follows:
  
  • pairdown
    You must specify use:serv_slow in this operand.
    There are times when you cannot confirm whether a server process has terminated, such as when a server process does not terminate at the source system or when HiRDB slows down. Such an event prevents any system switchover from being performed. When this operand is specified, the system is reset to allow execution of a system switchover when termination of processes cannot be confirmed for a reason such as a slowdown.
    
  • disk
    Omit this operand because HA Monitor does not perform access control on the shared disk.
    

(a) Configuring HiRDB system definition files

Use the same HiRDB system definitions in the primary system and the secondary system. Create the HiRDB system definitions for the primary system, and then copy those HiRDB system definitions to the secondary system. The following figures show configuration examples of HiRDB system definition files for a HiRDB single server configuration and a HiRDB parallel server configuration.

Figure 26-64 Configuration example of HiRDB system definition files when using the standby system switchover facility (for a HiRDB single server configuration)

Figure 26-65 Configuration example of HiRDB system definition files when using the standby system switchover facility (for a HiRDB parallel server configuration)

(b) HiRDB system definition operands to be set up when user server hot standby is used

This subsection explains the HiRDB system definition operands that you need to set up when user server hot standby is used. The following table lists the related operands.

Table 26-16 HiRDB system definition operands to be set up when user server hot standby is used

(c) HiRDB system definition operands to be set up when the rapid system switchover facility is used

This subsection explains the HiRDB system definition operands that you need to set up when the rapid system switchover facility is used. The following table lists the related operands.

Table 26-17 HiRDB system definition operands to be set up when the rapid system switchover facility is used

You define RDAREAs in HiRDB file system areas for RDAREAs on the shared disk. This subsection provides definition examples of creating user RDAREAs and system RDAREAs in HiRDB file system areas that are created on different shared disks. It also explains these concepts based on the system configuration examples in the following figures.

Figure 26-66 HiRDB single server configuration example

Example create rdarea statement specification

 
create rdarea SMAST for masterdirectory                   1
  file name "/sds0111/srd01" initial 10 segments;
create rdarea SDIR for datadirectory                      2
  file name "/sds0112/srd02" initial 5 segments;
create rdarea SDIC for datadictionary                     3
  file name "/sds0113/srd03" initial 20 segments;
create rdarea SUSR01 for user used by PUBLIC              4
  file name "/sds0121/srd04" initial 500 segments;
create rdarea SUSR02 for user used by PUBLIC              5
  file name "/sds0131/srd05" initial 500 segments;
 

Explanation

1. Creates the SMAST master directory RDAREA in the HiRDB file system area on shared disk A.
2. Creates the SDIR data directory RDAREA in the HiRDB file system area on shared disk A.
3. Creates the SDIC data dictionary RDAREA in the HiRDB file system area on shared disk A.
4. Creates the SUSR01 user RDAREA in the HiRDB file system area on shared disk B.
5. Creates the SUSR02 user RDAREA in the HiRDB file system area on shared disk C.
   

   Figure 26-67 HiRDB parallel server configuration example

   

Example create rdarea statement specification

 
create rdarea PMAST for masterdirectory                      1
    server name DIC file name "/dic0111/prd01"
    initial 10 segments;
create rdarea PDIR for datadirectory                         2
    server name DIC file name "/dic0112/prd02"
    initial 5 segments;
create rdarea PDIC for datadictionary                        3
    server name DIC file name "/dic0113/prd03"
    initial 20 segments;
create rdarea PUSR01 for user used by PUBLIC                 4
    server name BACK01 file name "/back0121/prd04"
    initial 500 segments;
create rdarea PUSR02 for user used by PUBLIC                 5
    server name BACK02 file name "/back0231/prd05"
    initial 500 segments;
 

Explanation

1. Creates the PMAST master directory RDAREA in the HiRDB file system area on shared disk A.
2. Creates the PDIR data directory RDAREA in the HiRDB file system area on shared disk A.
3. Creates the PDIC data dictionary RDAREA in the HiRDB file system area on shared disk A.
4. Creates the PUSR01 user RDAREA in the HiRDB file system area on shared disk B.
5. Creates the PUSR02 user RDAREA in the HiRDB file system area on shared disk C.

To allocate global buffers to the RDAREAS that you created above, perform the steps in Global buffer allocation procedures in the HiRDB Version 9 Installation and Design Guide.

Executor: HiRDB administrator or auditor

The HiRDB administrator creates audit trail files on a shared disk. The HiRDB administrator and the auditor can use the audit trail files on the shared disk.

(a) Creating audit trail files

The HiRDB administrator creates audit trail files on a shared disk.

(b) Using audit trail files

When a system switchover occurs, HiRDB records monitored events in an audit trail file on the shared disk. For details about operations involving audit trail files related to the recording of monitored events, see 24.6 Operation of audit trail files.

(c) Collecting audit trails

When a system switchover occurs, the way the audit trail collection status is inherited depends on whether the switched unit stops. If the system at the switching destination restarts, the status before the system switchover occurred is inherited. If the system at the switching destination starts normally, the specification in the pd_audit operand is used.

(d) Executing the pdload command

The HiRDB administrator executes the pdload command using the audit trail files as input information (certification is done by the auditor). However, if a factor such as an error caused a system switchover, HiRDB will not have correctly collected the audited events that occurred immediately before the system switchover. For this reason, even if the pdload command is executed, it might not be possible to collect the data that existed immediately before the system switchover.

When you use the NetBackup linkage facility in a system switchover configuration, the environment assignments and operations described below are necessary if the recovery is carried out on a NetBackup client different from the NetBackup client from which a backup was acquired. Apply these environment assignments and operations only when JP1/VERITAS NetBackup 5.0 or later is being used.

• Create the following empty file on the machine on which the NetBackup master server is installed:
  /usr/openv/NetBackup/db/altnames/No.Restrictions
  
• You need to change the NetBackup client name to be used for recovery (the client name to be set in the policy) to the NetBackup client name from which the backup data to be used for recovery was acquired. For details about how to change the NetBackup client name and other information, see the documentation included with NetBackup.