Cost-Effective High-Availability Solutions with HP Instant Capacity on HP-UX

The member failover can be accomplished in a manner similar to that described previously, but with
one change: since the member does not know which Group Manager might be active, the script to do
rights seizure must either try each Group Manager in turn, or use a relocatable IP address associated
with the Group Manager package to identify the Group Manager that is running.
Figure 19 shows the state after failover of both packages.
Figure 19: GiCAP/Serviceguard failover completed, including failover to standby Group Manager
Member failback considerations for db1 are exactly the same as described in the previous example.
Remember that if db1 is going to be offline for more than twelve hours, additional action may need to
be taken, as described in the “Recovery from a failure involving one or more nPartitions
” sub-section.
Extra care must be taken when considering failback of a Group Manager. When ap1 comes back
online, the package is restarted on ap1. If the package startup does icapmanage -Q -n to resume
control of the group, and if this is happens while ap2 is the Group Manager, it means that all
database changes done while ap2 was in control will be lost. To preserve database changes, what is
needed is to re-issue the icapmanage -Q -n command on the currently active Group Manager node first,
so that both Group Managers can synchronize information, and then issue the icapmanage -Q -n
command again on the node which is intended to be the active Group Manager (where the startup script
is operating). This is accomplished by doing the icapmanage-Q -n command in both the startup and
the shutdown scripts. For more information on sample scripts and additional scripting considerations,
see the Appendix.
36