25.13.1 Starting HiRDB (in the server mode)

Organization of this subsection
(1) HiRDB/Single Server
(2) HiRDB/Parallel Server (in the case of the standby system switchover facility)
(3) Standby-less system switchover (1:1) facility
(4) Standby-less system switchover (effects distributed) facility
(5) Notes

(1) HiRDB/Single Server

The procedure for starting a HiRDB/Single Server when using the system switchover facility is explained below.

Procedure:
  1. Use the pdstart command to start HiRDB on the running system.
  2. Use the pdstart command to start HiRDB on the standby system.

(2) HiRDB/Parallel Server (in the case of the standby system switchover facility)

Use the pdstart command to start HiRDB on the running system and the standby system.

Inheriting IP addresses
  • Starting HiRDB on the running system
    When starting HiRDB on the running system without allocating the IP address in advance, directly log onto the server machine of each unit and execute the pdstart -q command.
    If you allocate an IP address for each server machine and execute the pdstart command, you can start all units on the running system. When using HiRDB on the running system to start one unit at a time, be sure to allocate the IP address of the unit you will start first.
  • Starting HiRDB on the standby system
    Directly log onto a server machine that has standby system units and execute the pdstart -q command.
Not inheriting IP addresses
  • Starting HiRDB on the running system
    Directly log onto a server machine that has running system units and execute the pdstart -q command. Another method is to execute the pdstart command to start all units on the running system.
  • Starting HiRDB on the standby system
    Directly log onto a server machine that has standby system units and execute the pdstart -q command.

(3) Standby-less system switchover (1:1) facility

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

ObjectiveCommand to executeRemarks
Starting the normal BES unitpdstart -qIf 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 unitpdstart -qThe 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 portionpdstart -q -cNot 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.

(4) Standby-less system switchover (effects distributed) facility

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

ObjectiveCommand to executeRemarks
Starting the regular unitpdstart -qStarted when the regular unit is stopped.
Starting the accepting unitpdstart -qGuest BESs in the accepting unit are also started at the same time.
Starting the host BES or starting the guest BESpdstart -u -sIf 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.
(a) Starting the entire system

Table 25-24 shows how to start the entire system.

Table 25-24 Startup method for the entire system

Input locationCommandOperation
Unit where the system manager is definedpdstartStarts 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

[Figure]

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 typeIf standby-less system switchover (effects distributed) facility is applicable to the unit
NoYes
System startupStarts 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[Figure][Figure]
Solo-startup of other units[Figure][Figure]
Legend:
[Figure]: Not applicable
(b) Starting a unit

Table 25-26 shows how to start a unit.

Table 25-26 Unit startup method

Input locationCommandOptionOperation
-q-u
Unit where the system manager is definedpdstartNoYesStarts the target unit.
YesNo
Target unitpdstartYesNo

[Figure]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 modeHost BES or guest BESUnit startup mode
Startup of start serverStartup of restart server during startup of start server
Normal stopNoNoNormal start
YesNo
YesYes
Planned stop, forced termination, or abnormal terminationNoNoRestart
YesNo
YesYes

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

ItemContent
Configuration modification checkChecks 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 checkIf 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 inheritanceUnit 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.

[Figure]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]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

[Figure]

You can determine unit startup completion based on the output of the KFPS05110-I message:

(c) Starting a server

Table 25-29 shows how to start a server.

Table 25-29 Startup method for a server

Input locationCommandOptionOperation
-q-u-s
Unit where the system manager is definedpdstartNoNoYesStarts the target servers in all active units in an HA group1
YesNoYesStarts the host BES (-u may be omitted)2
1 The back-end servers in one of the units that are active in the HA group become the running servers and the other units are placed in accepting status.
2 When the target back-end servers are started successfully as running servers, the active units in the HA group are placed in accepting status automatically.

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 softwareServer typeOther units while the applicable server is activeActivation on the applicable host3Server startup result
HA monitorHost BESNo[Figure]Active
Yes[Figure]Accepting
Guest BESNo[Figure]Waits for running system to start1
Yes[Figure]Accepting
Hitachi HA Toolkit Extension[Figure]NoYesActive2
NoAccepting
YesYes[Figure]
NoAccepting
Legend:
[Figure]: Not applicable
1 HA monitor does not include the concepts of the running server and the standby server once a server has stopped. When the server starts again, the running system and the standby system are determined anew. In such a case, a secondary system (standby system in the default mode) waits for the running system to start when there is no running system. Therefore, if an active guest BES is stopped and then restarted at the same unit, it waits for the running system to start and does not return to active status until the monact command is executed.
2 Even after it stops a server, Hitachi HA Toolkit Extension makes the server appear to the cluster software to remain active. Therefore, when active servers, including guest BESs, are stopped and started on the same unit, they are placed on active status again.
3 This is equivalent to package activation in MC/ServiceGuard or group start in VERITAS Cluster Server.

[Figure]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]

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]

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

[Figure]

(5) Notes

Common notes
  • When executing the pdstart -q command, you must start all units within 20 minutes from the time the first unit starts. If all units cannot be started within 20 minutes, HiRDB startup processing terminates. Note that this value of 20 minutes for the startup time limit can be modified with the pd_reduced_check_time operand. The value of 20 minutes is the default for this operand.
  • The -i option, -r option, and dbdestroy option cannot be specified when HiRDB on a standby system executes the pdstart command.
  • Execute the pdstart -r command after HiRDB on the running system and standby system terminates. When the pdstart -r command is used to start HiRDB, HiRDB is not subject to system switchover. After a process such as database recovery processing terminates, terminate HiRDB then start it on the running system and standby system.
Notes on using the rapid system switchover facility
The notes explained here apply only when you are using Hitachi HA Toolkit Extension.
After startup processing for the running system unit is finished, start the standby system unit that uses the rapid system switchover facility. If the standby system unit is started before the running system unit has started, the standby system unit waits for startup of the running system unit to finish. If the running system unit does not start up within the waiting time limit, the standby system unit outputs abort code Phi1012 and terminates abnormally.
Notes on using the standby-less system switchover (1:1) facility
The notes explained here apply only when you are using Hitachi HA Toolkit Extension.
After starting either the normal BES unit or the alternate BES unit, start the other idle unit within 20 minutes. If the standby system unit is started before the running system unit has started, the standby system unit waits for startup of the running system unit to finish. If the running system unit does not start within the waiting time limit, the standby system unit outputs abort code Phi1012 and terminates abnormally.
During normal operation, the normal BES unit becomes the running system and the alternate portion becomes the standby system. When alternating units, the alternate portion becomes the running system and the normal BES unit becomes the standby system.
Notes on using MC/ServiceGuard
  • When starting HiRDB, the MC/ServiceGuard package must start normally on the running system. Therefore, before starting HiRDB, confirm that the package has started. Use MC/ServiceGuard commands to confirm that the package has started or to start a package.
  • When the running system unit has stopped (including when the unit terminates abnormally), MC/ServiceGuard may recognize that node as one that cannot be switched during a system switchover. In such a case, that node cannot be switched even if HiRDB is waiting. Use an MC/ServiceGuard command to place that node in system switchable status.
Notes on using Hitachi HA Toolkit Extension
If HiRDB is started without activating service processing for Hitachi HA Toolkit Extension, both systems will start as standby systems. In such a case, follow the applicable procedure explained in Table 25-31.
service processing for Hitachi HA Toolkit Extension

Table 25-31 Procedures to perform when HiRDB is started without activating service processing for Hitachi HA Toolkit Extension

ConditionProcedure
User server hot standby is applied to the unitMessage 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
  1. Use the terminate waiting system command of Hitachi HA Toolkit Extension to terminate both systems.
  2. Activate the cluster software on the running system.
  3. Start the running system unit.
  4. Confirm* that startup processing of the running system unit is finished, then start the standby system unit.
Rapid system switchover facility is applied to the unitMessage 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
  1. Activate the cluster software on the primary system.
  2. Start the primary system unit as the running system unit.
  3. Because the waiting time is elapsing, if the secondary system (standby system) unit terminates abnormally, confirm* that the startup process of the running unit is complete, and then start the standby system unit.
Starting the secondary system as the running system
  1. Use the pdstop -z (pdstop -f for a HiRDB/Single Server) command to terminate the secondary unit forcibly.
  2. Activate service processing for Hitachi HA Toolkit Extension on the secondary system.
  3. Start the secondary system unit as the running system unit.
  4. Confirm* that the startup process of the running unit is complete, and then start the standby system unit.
Unit for which the standby-less system switchover (1:1) facility is applicableMessage 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
  1. Activate service processing for Hitachi HA Toolkit Extension on the normal BES unit.
  2. Start the normal BES unit.
  3. Because the waiting time is elapsing, if the waiting status of the alternate portion is released, confirm* that the startup process of the normal BES unit is complete, and then place the alternate portion in waiting status.
Unit for which the standby-less system switchover (effects distributed) facility is applicableServers 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:

Notes about using the HA monitor
Before you start the running unit, use HA monitor's monshow command to make sure that the standby unit has stopped. The monshow command does not display any inactive system. If the command displays the status of the standby system, the standby status has not stopped.
An attempt to start the running unit immediately after its termination may result in output of the KFPS01878-I and KFPS00715-E messages, because the standby unit is still engaged in termination processing. If an attempt to start the running unit has failed, follow the procedure below to start the unit:
  1. Use HA monitor's monshow command to make sure that the standby unit has stopped.
  2. Execute the pdrpause command to restart HiRDB's process service.
  3. Use the pdstart command to start the running unit.