Under normal circumstances, an administrator performs daily administrative tasks on the configured MASTER machine. The DBBL on the
MASTER machine monitors other machines in a configuration, handles configuration updates, and broadcasts dynamic changes to the
TMIB. If the
MASTER machine fails, for example, due to a machine crash, database corruptions, Oracle Tuxedo system problems, network partitioning, or application faults, the application does not stop running. Clients can still join the application, servers can still service requests, and naming is still available on each local machine. However, until the
MASTER machine is restored, servers cannot be activated or deactivated, and an administrator cannot dynamically reconfigure the system.
A master migration is the process of moving the DBBL from the configured MASTER machine to the configured
BACKUP machine so that servers can continue to be serviced while the configured
MASTER machine is down. To start a migration, an administrator requests that the configured
BACKUP assume the role of acting
MASTER, and the configured
MASTER, the role of acting
BACKUP. The acting
MASTER then performs all administrative functions: it begins monitoring other machines in the configuration and accepts any dynamic reconfiguration changes.
InFigure 7‑1, Machine 2, the configured
BACKUP machine, assumes the role of
MASTER, while Machine 1, the configured
MASTER, assumes the role of acting
BACKUP. When the configured
MASTER is available again, it can be reactivated from the acting
MASTER (that is, the configured
BACKUP). The configured
MASTER then regains control as acting
MASTER.
In Figure 7‑2, GroupA is assigned to Machine 1 (that is, Machine 1 is configured as the primary machine); Machine 2 is configured as the alternate machine for GroupA. After migration, GroupA is activated on Machine 2, which means that all servers in this group and the services associated with them, are available on Machine 2 (the acting primary).
In Figure 7‑3, Machine 1 is the configured
MASTER and the primary machine for GroupB; Machine 2 is the configured
BACKUP. Server GroupB is configured with Machine 1 as its primary machine and Machine 3 as its alternate. If Machine 1 is taken down, Machine 2 becomes the acting
MASTER, and Server GroupB is deactivated, migrated to its alternate (Machine 3), and reactivated.
When a MASTER machine must be shut down for maintenance, or is no longer accessible due to an unanticipated problem (such as a partitioned network), then you must transfer the work of the
MASTER to a configured
BACKUP machine.
Note:
|
Before you can migrate the MASTER, both the MASTER and BACKUP machines must be running the same release of the Oracle Tuxedo system software.
|
The following two sample tmadmin sessions show how to switch
MASTER and
BACKUP machines regardless of whether the
MASTER machine is accessible from the
BACKUP machine. In
Listing 7‑1, the
MASTER machine is accessible, so the
DBBL process is migrated from the
MASTER to the
BACKUP.
In Listing 7‑2, because the
MASTER machine is not accessible from the
BACKUP machine, the
DBBL process is created on the
BACKUP machine on backup node (SITE2).
In Listing 7‑3 and
Listing 7‑4, after the old master (SITE1) becomes accessible again, execute the following commands to make the new MP mode work well. Make sure tlisten on both nodes starts up.
1.
|
Configure an alternate location in the LMID parameter (for the server group being migrated) in the GROUPS section of the UBBCONFIG file. Servers in the group must specify RESTART=Y and the MIGRATE option must be specified in the RESOURCES section of the UBBCONFIG file.
|
3.
|
Start a tmadmin session by entering the following command:
|
4.
|
At the tmadmin prompt, enter one of the following commands:
|
1.
|
From the MASTER machine, shutdown the group to be migrated by entering the following command:
|
In Listing 7‑6, the alternate machine is not accessible from the primary machine.
1.
|
Use the LMID parameter to name the processor on which the server group(s) have been running. The alternate location must be the same for all server groups on the LMID.
|
2.
|
In the RESOURCES section of the UBBCONFIG file, set the following parameters:
|
•
|
Set RESTART=Y for each server on the machine indicated by the LMID.
|
4.
|
Use the tmadmin(1) migratemach ( migm) command to migrate all server groups from one machine to another when the primary machine must be shut down for maintenance or when the primary machine is no longer accessible. (The command takes one logical machine identifier as an argument.)
|
1.
|
From the MASTER machine, shutdown the primary machine to be migrated by entering the following command:
|
2.
|
On the MASTER machine, start a tmadmin session by entering the following command:
|
3.
|
At the tmadmin prompt, migrate the appropriate machine by entering the following command:
|
Listing 7‑7 shows how to migrate machines. In the first example, the alternate machine is accessible from the primary machine.
In Listing 7‑8, the alternate machine is not accessible from the primary machine.
DBBLFAILOVER*SANITYSCAN*SCANUNIT is the time threshold for migrating
DBBL. This parameter is specified in seconds, or milliseconds if
SCANUNIT is specified in
milliseconds. If not specified,
DBBLFAILOVER will be set as 0 by default. The Automatic Migration for DBBL will be enabled only if
DBBLFAILOVER is configured greater than 0.
SGRPFAILOVER*SANITYSCAN*SCANUNIT is the time threshold for migrating server groups. This parameter is specified in seconds, or milliseconds if
SCANUNIT is specified in
milliseconds. If not specified,
SGRPFAILOVER will be set as 0 by default. The Automatic Migration for server groups will be enabled only if
SGRPFAILOVER is configured greater than 0.
The following sample tmadmin session in
Listing 7‑9 shows how a server group and a machine can be migrated between their respective primary and alternate machines.
1.
|
Start a tmadmin session by entering the following command:
|
3.
|
Dump the TLOG into a text file by running the following command:
|
dumptlog [-z config] [-o offset] [-n filename] [-g groupname]
Note:
|
The TLOG is specified by the config and offset arguments. The value of offset defaults to 0; name defaults to TLOG. If the -g option is chosen, only those records coordinated by the TMS from groupname are dumped.
|
4.
|
Copy filename to the BACKUP machine.
|