Administering an Oracle Tuxedo Application at Run Time

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Migrating Your Application

This topic includes the following sections:

 


What Is Migration?

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.

Similarly, application servers are configured to run on specific machines to service client requests. However, if a machine fails or must be brought down to be serviced, the servers on that machine become unavailable. In each case, you can migrate the servers to a configured BACKUP or alternate machine.

An administrator who performs a migration in preparation for shutting down a machine for service or upgrading, does not face the problems inherent in a machine failure. Therefore an administrator in this situation has a relatively high degree of control over migration activities.

Performing a Master Migration

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.

Figure 7-1 Perfoming a Master Migration

Perfoming a Master Migration

Migrating a Server Group

For each group of servers, an administrator specifies a primary machine and an alternate machine. The process of migrating a server group involves activating the server group on the alternate machine.

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).

Figure 7-2 Migrating a Server Group

Migrating a Server Group

Migrating Machines

While it is sometimes useful to migrate only a single server group, it is more often necessary to migrate an entire machine. This type of migration may be necessary, for example, when a computer fails. Migrating a machine involves migrating each of the server groups running on the machine. An alternate machine must be configured for each server group.

Performing a Scheduled Migration

In a controlled situation, such as when a computer needs to be offline for a while, or needs to be upgraded, an administrator can preserve information about the current configuration for servers and services, and use that information when activating servers on alternate machines. Such use of configuration information is possible because server entries are retained on a primary machine, even after the servers are deactivated and become unavailable in response to a request for a migration.

You can migrate an entire server group or an entire machine. Migration of an entire machine is possible when the same machine is configured as the alternate for all the server groups on a primary machine. When that is not the case (that is, when different alternate machines are configured for different server groups on a primary machine), then the servers must be migrated by group, rather than by machine.

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.

Figure 7-3 Performing a Scheduled Migration

Performing a Scheduled Migration

After deactivating all the servers in a group, you can migrate the group from the acting primary to the acting alternate. You do not need to specify which servers are running, which services are currently advertised, or which, if any, dynamic configuration changes are being made. The configured alternate machine obtains this information from the configuration information for the servers that is available on the configured primary machine, when the servers are deactivated. If data-dependant routing is being used and will continue to be used on the alternate machine, services are routed on the basis of the target group name, instead of the target machine name.

Whether you need to migrate an entire application or only portions of it, be sure to make the necessary changes with minimal service disruption. The integrity of all machines, networks, databases, and other components of your application must remain intact. The Oracle Tuxedo system provides a way to migrate an application while preserving the integrity of all its components.

 


Migration Options

The Oracle Tuxedo system allows you to migrate:

You can also cancel a migration.

By migrating a combination of the application components listed here, and using the system utilities for recovering a partitioned network, you can migrate entire machines.

 


How to Switch the Master and Backup Machines

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.

This type of switching is done by migrating the DBBL from the MASTER to the BACKUP. To migrate the DBBL, enter the following command:

tmadmin master

In most cases, you need to migrate application servers to alternate sites, or restore the MASTER machine. For more detail about the tmadmin command, see the tmadmin(1) reference page in the File Formats, Data Descriptions, MIBs, and System Processes Reference.

Examples of Switching MASTER and BACKUP Machines

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.

Listing 7-1 Switching MASTER and BACKUP When MASTER Is Accessible from BACKUP
$ tmadmin
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL. All rights reserved.
> master
are you sure? [y,n] y
Migrating active DBBL from SITE1 to SITE2, please wait...
DBBL has been migrated from SITE1 to SITE2
> q

In Listing 7-2, because the MASTER machine is not accessible from the BACKUP machine, the DBBL process is created on the BACKUP machine.

Listing 7-2 Switching MASTER and BACKUP When MASTER Is Not Accessible from BACKUP
$ tmadmin
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL. All rights reserved.
TMADMIN_CATT:199: Cannot become administrator. Limited set of commands available.
> master
are you sure? [y,n] y
Creating new DBBL on SITE2, please wait... New DBBL created on SITE2
> q

 


How to Migrate Server Groups

  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.
  2. If you are planning to migrate a group of servers, shut down each server in the group by issuing the following command:
  3. tmshutdown -R -g groupname
  4. Start a tmadmin session by entering the following command:
  5. tmadmin
  6. At the tmadmin prompt, enter one of the following commands:
    • To migrate all the servers in a single group, enter:
    • migrategroup(migg)

      This command takes the name of a single server group as an argument.

    • To migrate all the server groups on a machine (as specified by an LMID), enter:
    • migratemach(migm)
  7. If transactions are being logged for a server being migrated as part of a group, you may need to move the TLOG to the BACKUP machine, load it, and “warm start” it.

How to Migrate a Server Group When the Alternate Machine Is Accessible from the Primary Machine

To migrate a server group when the alternate machine is accessible from the primary machine, complete the following procedure.

  1. Shut down the MASTER machine by entering the following command:
  2. tmshutdown -R -g groupname
  3. On the primary machine, start a tmadmin session by entering the following command:
  4. tmadmin
  5. Migrate the appropriate group by entering the following command:
  6. migrategroup groupname
  7. If necessary, migrate the transaction log.
  8. If necessary, migrate the application data.

How to Migrate a Server Group When the Alternate Machine Is Not Accessible from the Primary Machine

To migrate a server group when the alternate machine is not accessible from the primary machine, switch the MASTER and BACKUP machines, if necessary.

  1. On the alternate machine, start a tmadmin session by entering the following command:
  2. tmadmin
  3. Request cleanup and restart of any servers on the primary machine that require these operations by entering the following command:
  4. pclean primary_machine
  5. Transfer the appropriate server group to a configured alternate machine by entering the following command:
  6. migrate groupname
  7. Boot the newly migrated server group by entering the following command:
  8. boot -g groupname

Examples of Migrating a Server Group

The following two sample sessions show how you can migrate a server group, regardless of whether the alternate machine is accessible from the primary machine. In Listing 7-3, the alternate machine is accessible from the primary machine.

Listing 7-3 Migrating a Group When the Alternate Machine Is Accessible from the Primary Machine
$ tmshutdown -R -g GROUP1
Shutting down server processes...
Server ID = 1 Group ID = GROUP1 machine = SITE1: shutdown succeeded
1 process stopped.
$ tmadmin
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL.
> migg GROUP1
migg successfully completed
> q

In Listing 7-4, the alternate machine is not accessible from the primary machine.

Listing 7-4 Migrating a Group When the Alternate Machine Is Not Accessible from the Primary Machine
$ tmadmin
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL.
> pclean SITE1
Cleaning the DBBL.
Pausing 10 seconds waiting for system to stabilize.
3 SITE1 servers removed from bulletin board
> migg GROUP1
migg successfully completed.
> boot -g GROUP2
Booting server processes ...
exec simpserv -A :
on SITE2 -> process id=22699 ... Started.
1 process started.
> q

 


How to Migrate Server Groups from One Machine to Another

  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.
    • Specify the MIGRATE options.
  3. Shut down all server groups and mark the servers in the groups as restartable by entering the following command:
  4. tmshutdown -R
  5. 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.)

How to Migrate Machines When the Alternate Machine Is Accessible from the Primary Machine

To migrate a machine when the alternate machine is accessible from the primary machine, complete the following procedure.

  1. Shut down the MASTER machine by entering the following command on that machine:
  2. tmshutdown -R -1 primary_machine
  3. On the MASTER machine, start a tmadmin session by entering the following command:
  4. tmadmin
  5. At the tmadmin prompt, migrate the appropriate machine by entering the following command:
  6. migratemach primary_machine
  7. If necessary, migrate the transaction log.
  8. If necessary, migrate the application data.

How to Migrate Machines When the Alternate Machine Is Not Accessible from the Primary Machine

To migrate a machine when the alternate machine is not accessible from the primary machine, switch the MASTER and BACKUP machines, if necessary.

  1. On the alternate machine, start a tmadmin session by entering the following command:
  2. tmadmin
  3. Request cleanup and restart of the primary machine that require these operations by entering the following command:
  4. pclean primary_machine
  5. Transfer the appropriate server group to a configured alternate machine by entering the following command:
  6. migratemach primary_machine
  7. Boot the newly migrated server group by entering the following command:
  8. boot -l alternate_machine

Examples of Migrating a Machine

Listing 7-5 shows how to migrate machines. In the first example, the alternate machine is accessible from the primary machine.

Listing 7-5 Migrating a Machine When the Alternate Machine Is Accessible from the Primary Machine
$ tmshutdown -R -l SITE1
Shutting down server processes...
Server ID = 1 Group ID = GROUP1 machine = SITE1: shutdown
succeeded 1 process stopped.
$ tmadmin
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL.
> migm SITE1
migm successfully completed
> q

In Listing 7-6, the alternate machine is not accessible from the primary machine.

Listing 7-6 Migrating a Machine When the Alternate Machine Is Not Accessible from the Primary Machine
$ tmadmin
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL.
>pclean SITE1
Cleaning the DBBL.
Pausing 10 seconds waiting for system to stabilize.
3 SITE1 servers removed from bulletin board
> migm SITE1
migm successfully completed.
> boot -l SITE2
Booting server processes ...
exec simpserv -A :
on SITE2 -- process id=22782 ... Started.
1 process started.
>q

 


How to Cancel a Migration

If you decide, after deactivating a server group or machine, that you do not want to continue, you can cancel the migration before reactivating the server group or machine. All the information in the name server for the deactivated servers and services is deleted.

To cancel a migration after a shutdown but before issuing the migrate command, enter one of the following commands shown in Table 7-1.

Table 7-1 How to Cancel a Migration
To Cancel . . .
Enter This Command . . .
As a Result . . .
Server migration
tmadmin migrategroup -cancel
or
tmadmin migg -cancel
Server entries are deleted from the bulletin board. You must reboot the servers once the migration procedure is canceled.
Machine migration
tmadmin migratemach -cancel
or
tmadmin migm -cancel
The migration is stopped.

Example of a Migration Cancellation

The following sample tmadmin session in Listing 7-7 shows how a server group and a machine can be migrated between their respective primary and alternate machines.

Listing 7-7 Canceling a Server Group Migration for GROUP1
$tmadmin  
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL.
> psr -g GROUP1
a.out Name  Queue Name    Grp Name   ID RqDone Ld Done Current Service
---------- ---------- -------- -- ------ ------- ---------------
simpserv 00001.00001 GROUP1 1 - - (DEAD MIGRATING)
> psr -g GROUP1
TMADMIN_CAT:121: No such server
migg -cancel GROUP1
>boot -g GROUP1
Booting server processes...
exec simpserv -A:
on SITE1 ->process id_27636 ... Started. 1 process started.
> psr -g GROUP1
a.out Name  Queue Name    Grp Name   ID RqDone Ld Done Current Service
---------- ---------- -------- -- ------ ------- ---------------
simpserv 00001.00001 GROUP1 1 - - ( - )
> q

 


How to Migrate Transaction Logs to a Backup Machine

To migrate a transaction log to a BACKUP machine, complete the following procedure.

  1. Start a tmadmin session by entering the following command:
  2. tmadmin
  3. Shut down the servers in all the groups that write to the log, to prevent them from writing further entries.
  4. Dump the TLOG into a text file by running the following command:
  5. 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.
  6. Copy filename to the BACKUP machine.
  7. Read the file into the existing TLOG for the specified machine by entering the following command:
  8. loadtlog -m machine filename
  9. Force a warm start of the TLOG by entering the following command:
  10. logstart machine

    The system reads the information in the TLOG and uses it to create an entry in the transaction table in shared memory.

  11. Migrate the servers to the BACKUP machine.

  Back to Top       Previous  Next