edocs Home > Oracle WebLogic Server Documentation > Administration Console Online Help > Servers: Configuration: Migration

Servers: Configuration: Migration

Configuration Options     Related Tasks     Related Topics

If a clustered server fails, WebLogic Server can automatically restart (migrate) the server and its services on another machine. Alternatively, you can configure options for the JMS-related services (such as JMS servers, SAF agents, path service, and custom persistent stores) and the JTA Transaction Recovery Service on this server so that they can be manually migrated to another server. You can also specify to have the JTA Transaction Recovery Service automatically migrated to another server.

Use this page to enable server migration or to configure services-only migration.

Configuration Options

Name Description
Candidate Machines

Limits the list of candidate machines that the cluster specifies. (Requires you to enable this server for automatic migration and to configure the cluster with a set of candidate machines.)

If this server fails and if it is enabled for automatic migration, Node Manager automatically restarts it. By default, Node Manager restarts the server on any of the candidate machines that the cluster specifies (in order of preference that you configured in the cluster). To change the default, you use this server's list of candidate machines to create a subset of the cluster-wide candidates. You can also change the order of preference.

MBean Attribute:
ServerMBean.CandidateMachines

Changes take effect after you redeploy the module or restart the server.

Automatic Server Migration Enabled

Whether Node Manager can automatically restart this server and its services on another machine if the server fails.

MBean Attribute:
ServerMBean.AutoMigrationEnabled

Changes take effect after you redeploy the module or restart the server.

JMS Service Candidate Servers

Select servers in the cluster to use as a backup for this server's JMS-related services, such as JMS servers, SAF agents, path service, and WebLogic persistent stores.

Automatic JTA Migration Enabled

Enable automatic migration of the JTA Transaction Recovery System on this server.

JTA Candidate Servers

Select servers that can access the JTA log files (in the WebLogic default persistent store) for the current server.

To migrate the Transaction Recovery Service from a failed server in a cluster to another server (backup server) in the same cluster, the backup server must have access to the transaction log files from the failed server. WebLogic Server uses the WebLogic default persistent store to store transaction log files. Therefore, configure the default persistent store to store its data files in a file system on a shareable storage solution, such as a Storage Area Network (SAN) device or a dual-ported disk, that is available to both the primary server and the server that will act as its backup. When using the automatic service migration option, the default persistent store cannot be shared by JTA and other migratable services; only JTA and other non-migratable services can share the same default persistent store.

Pre-Migration Script Path

Specifies the path to the pre-migration script to run before a migratable target is actually activated. The script must be in the BEA_HOME/user_projects/domains/mydomain/bin/service_migration directory.

Before the migratable target is activated, if there is a script specified, and Node Manager is available, then the script will run. Specifying a script without an available Node Manager will result in an error upon migration.

If the script fails or cannot be found, migration will not proceed on the current server, and will be tried on the next suitable server. This could be the next server in the candidate server list, or in the cluster, if there is no candidate server list.

MBean Attribute:
MigratableTargetMBean.PreScript

Changes take effect after you redeploy the module or restart the server.

Post-Migration Script Path

Specifies the path to the post-migration script to run after a migratable target is fully deactivated. The script must be in the BEA_HOME/user_projects/domains/mydomain/bin/service_migration directory.

After the migratable target is deactivated, if there is a script specified, and Node Manager is available, then the sript will run. Specfiying a script without an available Node Manager will result in an error upon migration.

MBean Attribute:
MigratableTargetMBean.PostScript

Changes take effect after you redeploy the module or restart the server.

Post-Migration Script Failure Cancels Automatic Migration

Whether or not a failure during execution of the post-deactivation script is fatal to the migration.

If it is fatal, the migratable target will not be automatically migrated until an administrator manually migrates it to a server, thus reactivating it.

Note: Enabling this value will result in weakening the exactly-once guarantee. It is provided to prevent more dangerous data corruption if the post-deactivation script fails. Also if this value is enabled, then the script may be called more than once by the migration framework after the Migratable Target is deactivated or the server or machine hosting the Migratable Target crashed or is network partitioned. The script is expected not to return different exit values when invoked multiple times in such scenarios.

MBean Attribute:
MigratableTargetMBean.PostScriptFailureFatal

Changes take effect after you redeploy the module or restart the server.

Allow Post-Migration Script to Run On a Different Machine

Whether or not the post-deactivation script is allowed to run on a different machine.

Normally, when automigration occurs, the post-deactivation script will be run on the service's current location, and the pre-activation script on the service's new location. If the current location is unreachable for some reason, this value will be checked to see if it is safe to run it on the service's new machine.

This is useful if the post-deactivation script controls access to a networked resource and does not need any data from the current machine.

MBean Attribute:
MigratableTargetMBean.NonLocalPostAllowed

Changes take effect after you redeploy the module or restart the server.

Enable Strict Ownership Check

Whether continue to boot if cannot find the current owner of TRS to do failback. This attribute is only meaningful for servers in cluster.

If true: server will fail to boot under this situation.

If false: server will continue to boot without trying to do failback.

MBean Attribute:
JTAMigratableTargetMBean.StrictOwnershipCheck

Related Tasks

Related Topics