Nonstop Database, HiRDB Version 9 System Operation Guide
26.2.4 HiRDB preparations
(1) Conditions and notes
(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.
- 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.
- Notes on using ClusterPerfect
- Use the command below to stop the ClusterPerfect daemon before setting up the HiRDB environment. To execute this command, you must have root privileges:
- # /etc/rc.d/init.d/dncware_daemon stop
- Execute the following command to start the ClusterPerfect daemon:
- # /etc/rc.d/init.d/dncware_daemon start
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-28 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)
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. This shared disk access control is performed by either 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 the 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-29 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 of 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:
- A failure that triggers a system switchover occurs.
- HiRDB confirms that all server processes (HiRDB processes) have terminated in the source system.
- The system switchover takes place.
- The target system starts accessing the shared disk.
- The following figure shows the shared disk access control that is provided by HiRDB.
Figure 26-30 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.
- 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 is not used to 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-31 Configuration example of HiRDB system definition files when using the standby system switchover facility (for a HiRDB single server configuration)
Figure 26-32 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 the monitor mode is used
This subsection explains the HiRDB system definition operands that you need to set up when the monitor mode is used. The following table lists the related operands.
Table 26-12 HiRDB system definition operands to be set up when the monitor mode is used
Operand |
Explanation and notes |
pd_ha |
Specifies to use the system switchover facility. |
pd_ha_ipaddr_inherit |
Specifies whether to inherit IP addresses after a system switchover. If a multi-standby configuration is applied, specify Y.
Y: Inherit IP addresses.
N: Do not inherit IP addresses. |
pd_ha_unit |
Do not specify this operand if a system switchover facility is used on the unit.
If the system includes a unit to which you do not want to apply the system switchover facility, or it includes a recovery-unnecessary front-end server unit, specify nouse for the pd_ha_unit operand of the unit control information definition of that unit. |
pd_ha_acttype |
Specifies whether to use the system switchover facility in the monitor mode or the server mode. If the system switchover facility uses Sun Cluster, HACMP, PowerHA, ClusterPerfect, or LifeKeeper, the server mode cannot be used. You must use the monitor mode.
monitor: Operate the system switchover facility in the monitor mode.
server: Operate the system switchover facility in the server mode. |
pd_ha_restart_failure |
This operand can be specified when the monitor mode is used. It is ignored in the server mode, even if it is specified.
This operand specifies a command to be executed if restarting of HiRDB fails. |
pd_mode_conf |
This operand is related to HiRDB (or unit) startup. Specify a value as explained in the following:
If you use the monitor mode, specify MANUAL1. |
pd_hostname |
Specifies the standard host name of the primary system. |
pdunit |
-x |
Specifies the host name of the primary system. If you are using a multi-standby configuration, specify the name of the host that inherits the IP address. |
-u |
Specifies the unit identifier. |
-d |
Specifies the HiRDB directory name. If you are using a multi-standby configuration, specify the same directory name in the primary system and all secondary systems. |
-c |
Specifies the host name of the secondary system. Specify this option when IP addresses are not inherited after a system switchover. |
-p |
Specifies a HiRDB port number. |
-s |
Specifies a scheduler port number. |
-t |
Specifies a transaction server port number. |
pd_service_port |
Exercise care when specifying this operand in a server machine configuration that includes multiple units (including a mutual system switchover configuration). For such configurations (including a mutual system switchover configuration), use this operand to specify a separate port number for each unit in its unit control information definition.
If either of the following is specified, system switchovers to one of the units fail:
- The pd_service_port operand of the system common definition is specified (when the pd_service_port operand of the unit control information definition is not specified).
- A port number that is specified in the pd_service_port operand of another unit control information definition is specified in the pd_service_port operand of the unit control information definition.
|
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-33 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
- Creates the SMAST master directory RDAREA in the HiRDB file system area on shared disk A.
- Creates the SDIR data directory RDAREA in the HiRDB file system area on shared disk A.
- Creates the SDIC data dictionary RDAREA in the HiRDB file system area on shared disk A.
- Creates the SUSR01 user RDAREA in the HiRDB file system area on shared disk B.
- Creates the SUSR02 user RDAREA in the HiRDB file system area on shared disk C.
Figure 26-34 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
- Creates the PMAST master directory RDAREA in the HiRDB file system area on shared disk A.
- Creates the PDIR data directory RDAREA in the HiRDB file system area on shared disk A.
- Creates the PDIC data dictionary RDAREA in the HiRDB file system area on shared disk A.
- Creates the PUSR01 user RDAREA in the HiRDB file system area on shared disk B.
- Creates the PUSR02 user RDAREA in the HiRDB file system area on shared disk C.
(5) Defining global buffers
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.
(7) Notes on using the NetBackup linkage facility
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.
All Rights Reserved. Copyright (C) 2011, 2015, Hitachi, Ltd.