The procedure for starting a HiRDB/Single Server when using the system switchover facility is explained below.
Use the pdstart command to start HiRDB on the running system and the standby system.
Table 25-22 lists the methods of starting the normal BES unit and alternate BES unit.
Table 25-22 HiRDB startup methods when using the standby-less system switchover (1:1) facility
Objective | Command to execute | Remarks |
---|---|---|
Starting the normal BES unit | pdstart -q | If this command is executed when a normal BES unit has stopped when alternating units, the normal BES unit is placed in waiting status.1 |
Starting the alternate BES unit | pdstart -q | The alternate portion in the alternate BES unit is also started. The alternate portion is placed in waiting status2 if it was in normal status. |
Starting the alternate portion | pdstart -q -c | Not necessary because HiRDB starts automatically. The command needs to be executed only when the alternate portion is stopped or is to be reactivated. |
Note: Startup cannot be performed at the server level.
1 The system will only be switched back to the normal BES unit if the normal BES unit is in waiting status (that is, it will not be switched back to normal status from alternating status). If the normal BES unit is in waiting status, the system status is displayed as SBY in the execution results of the pdls -d ha command.
2 System switching only occurs when the alternating portion is in waiting status. If the alternate BES unit is in waiting status, the system status is displayed as SBY in the execution results of the pdls -d ha command.
Table 25-23 shows how to start the regular unit and a guest BES unit.
Table 25-23 HiRDB startup methods when using the standby-less system switchover (effects distributed) facility
Objective | Command to execute | Remarks |
---|---|---|
Starting the regular unit | pdstart -q | Started when the regular unit is stopped. |
Starting the accepting unit | pdstart -q | Guest BESs in the accepting unit are also started at the same time. |
Starting the host BES or starting the guest BES | pdstart -u -s | If a guest BES is stopped, it is placed in accepting status. In general, it is not necessary to use this command because HiRDB starts automatically; this command is needed only when a back-end server or its standby server was stopped explicitly. |
Table 25-24 shows how to start the entire system.
Table 25-24 Startup method for the entire system
Input location | Command | Operation |
---|---|---|
Unit where the system manager is defined | pdstart | Starts the entire system. |
The process of starting the entire system is explained below.
Figure 25-56 shows an example of starting the entire system when the standby-less system switchover (effects distributed) facility is used.
To start the entire system, enter the pdstart command from the unit where the system manager is defined, as is the case when standby system switchover is used. The guest BESs in each unit are placed in accepting status automatically.
Figure 25-56 Example of starting the entire system when the standby-less system switchover (effects distributed) facility is used
Table 25-25 shows the system startup operations. When system startup is completed, the KFPS05210-I message is output.
Table 25-25 System startup operations
Start type | If standby-less system switchover (effects distributed) facility is applicable to the unit | |
---|---|---|
No | Yes | |
System startup | Starts all units (All servers start). | Starts all servers (Not all units start). |
Solo-startup of the unit where the system manager is defined (after abnormal termination of the unit where the system manager is defined) | Starts one front-end server, one dictionary server, and one back-end server. | Starts one front-end server, one dictionary server, and one back-end server. |
Solo-startup of a unit in an HA group | ![]() | ![]() |
Solo-startup of other units | ![]() | ![]() |
Table 25-26 shows how to start a unit.
Table 25-26 Unit startup method
Input location | Command | Option | Operation | |
---|---|---|---|---|
-q | -u | |||
Unit where the system manager is defined | pdstart | No | Yes | Starts the target unit. |
Yes | No | |||
Target unit | pdstart | Yes | No |
Startup modes for units
Table 25-27 shows the unit startup modes. Whether a unit is to be started normally or restarted is determined exclusively by the unit's previous termination mode; it is not affected by the presence or absence of a host BES or guest BES that starts, or by normal start or restart of the server that starts.
Table 25-27 Unit startup modes
Unit's previous termination mode | Host BES or guest BES | Unit startup mode | |
---|---|---|---|
Startup of start server | Startup of restart server during startup of start server | ||
Normal stop | No | No | Normal start |
Yes | No | ||
Yes | Yes | ||
Planned stop, forced termination, or abnormal termination | No | No | Restart |
Yes | No | ||
Yes | Yes |
When the standby-less system switchover (effects distributed) facility is used, determination and processing of restart or normal start is executed for each user server. Therefore, the unit can start normally even when another server within the unit has been terminated forcibly or abnormally or is running on another unit in the HA group.
Also when the standby-less system switchover (effects distributed) facility is used, a unit is restarted after it has been terminated forcibly or abnormally. Because restart processing is executed for each user server, there is no resource (database) to be restored for the unit itself. However, as usual, the operations during unit restart are different from those during a normal start, as shown in Table 25-28.
Table 25-28 Significance of unit restart
Item | Content |
---|---|
Configuration modification check | Checks for definition modifications that increase system resources (such as shared memory) to eliminate the risk of a restart failure (the number of guest BESs that can be accepted can be changed). |
System startup completion check | If there is one front-end server, one dictionary server, and one back-end server available during the restart of the unit where the system manager is defined, system startup is considered complete and service begins. During normal startup of the unit where the system manager is defined, the system waits for all servers to be completely started. However, during a restart of the unit where the system manager is defined, the number of servers to wait for is reduced, resulting in an earlier resumption of service acceptance. |
Unit run ID inheritance | Unit run ID is inherited before the unit stops. It is used as the reference for output of the KFPS01826-I message during unit startup and for regular and automatic execution of pdcspool. |
Unit startup example
Figure 25-57 shows an example of unit start when the standby-less system switchover (effects distributed) facility is used. Start the unit as follows:
As the unit starts, the system changes the status of the following guest BESs:
Figure 25-57 Unit startup example when the standby-less system switchover (effects distributed) facility is used
Unit startup example when there is no running system back-end server
Figure 25-58 shows an example of starting a unit that has no running system back-end server when the standby-less system switchover (effects distributed) facility is used.
The following methods are available for starting the unit:
As the unit starts, the system changes the status of the guest BESs in the unit (Automatic status change 1 in the figure).
Figure 25-58 Example of starting a unit that has no running system back-end server when the standby-less system switchover (effects distributed) facility is used
You can determine unit startup completion based on the output of the KFPS05110-I message:
Table 25-29 shows how to start a server.
Table 25-29 Startup method for a server
Input location | Command | Option | Operation | ||
---|---|---|---|---|---|
-q | -u | -s | |||
Unit where the system manager is defined | pdstart | No | No | Yes | Starts the target servers in all active units in an HA group1 |
Yes | No | Yes | Starts the host BES (-u may be omitted)2 |
Table 25-30 shows the processing results during server startup depending on the cluster software used.
Table 25-30 Processing results during server startup
Cluster software | Server type | Other units while the applicable server is active | Activation on the applicable host3 | Server startup result |
---|---|---|---|---|
HA monitor | Host BES | No | ![]() | Active |
Yes | ![]() | Accepting | ||
Guest BES | No | ![]() | Waits for running system to start1 | |
Yes | ![]() | Accepting | ||
Hitachi HA Toolkit Extension | ![]() | No | Yes | Active2 |
No | Accepting | |||
Yes | Yes | ![]() | ||
No | Accepting |
Server startup example
Figure 25-59 shows an example of starting a running system server when the standby-less system switchover (effects distributed) facility is used.
The following method is available for starting the running system server:
As the server starts, the system changes the status of the guest BESs corresponding to the server (Automatic status change in the figure).
To check whether the server is the running system, use the pdls -d ha command.
Figure 25-59 Example of starting a running system server when the standby-less system switchover (effects distributed) facility is used
Figure 25-60 shows an example of starting a standby system server when the standby-less system switchover (effects distributed) facility is used.
The following method is available for starting a standby system server:
The specified host BES is placed in accepting status. To check whether the server is the running system, use the pdls -d ha command.
Figure 25-60 Example of starting a standby system server when the standby-less system switchover (effects distributed) facility is used
Figure 25-61 shows an example of a guest server status change when the standby-less system switchover (effects distributed) facility is used.
The following method is available to make a guest BES in a unit accepting:
The specified guest BES is placed in accepting status.
Figure 25-61 Status change example of a guest server when the standby-less system switchover (effects distributed) facility is used
Table 25-31 Procedures to perform when HiRDB is started without activating service processing for Hitachi HA Toolkit Extension
Condition | Procedure |
---|---|
User server hot standby is applied to the unit | Message KFPS01872-I, which indicates that both systems started as standby systems, is output. This message is output to both systems. The procedure for resolving this problem is explained below. Procedure
|
Rapid system switchover facility is applied to the unit | Message KFPS01854-E is output and the primary system unit terminates abnormally (abort code: Psadhfe). The secondary system unit waits for the primary system unit to start as the running system unit. The procedures for resolving this problem are explained below. Starting the primary system as the running system
|
Unit for which the standby-less system switchover (1:1) facility is applicable | Message KFPS01854-E is output and the normal BES unit terminates abnormally (abort code: Psdahfe). The alternate portion waits for the normal BES unit to start. The procedure for resolving this problem is explained below. Procedure
|
Unit for which the standby-less system switchover (effects distributed) facility is applicable | Servers in both the running system and the standby system are placed in standby status and can be operated by the user. Neither system is terminated abnormally. In this case, you can activate the cluster software on the host on which the server becomes the running system and complete the startup process (start the service process of Hitachi HA Toolkit Extension). |
* You can use the following to confirm that unit startup processing is complete: