| |
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 and JTA services on this server so that you can manually migrate the services 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.CandidateMachinesChanges take effect after you redeploy the module or restart the server.
Auto Migration Enabled Specifies whether Node Manager can automatically restart this server and its services on another machine if the server fails.
MBean Attribute:
ServerMBean.AutoMigrationEnabledChanges take effect after you redeploy the module or restart the server.
JMS Candidate Servers Select servers in the cluster to use as a backup for this server's JMS services.
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, you must configure the default persistent store to store its data files in a file system on persistent storage, such as a Storage Area Network (SAN) device or a dual-ported disk, available to both the primary server and the server that will act as its backup.
Automatic JTA Migration Enabled Enable automatic migration of this this server
Pre Script Sets the script to run before a Migratable Target is actually activated. Before the target is activated, if there is a script specified and NodeManager available, we will run the script. Setting a script without a NodeManager available 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. (The next server in the candidate server list, or the cluster, if there is no candidate server list.)
MBean Attribute:
MigratableTargetMBean.PreScriptChanges take effect after you redeploy the module or restart the server.
Post Script Sets the script to run after a Migratable Target is fully deactivated. After the target is deactivated, if there is a script specified and NodeManager available, we will run the script. Setting a script without a NodeManager available will result in an error upon migration.
MBean Attribute:
MigratableTargetMBean.PostScriptChanges take effect after you redeploy the module or restart the server.
Post Script failure cancels automatic migration Returns whether or not a failure during execution of post-deactivation script is fatal to the migration or not. If it is, the migratable target will not be automatically migrated until an administrator manually migrates it to a server, thus reactivating it. 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 and is not idempotent.
MBean Attribute:
MigratableTargetMBean.PostScriptFailureFatalChanges take effect after you redeploy the module or restart the server.
Allow Post Script to run on different machine Returns whether or not it is allowed to run the post-deactivation script 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.NonLocalPostAllowedChanges take effect after you redeploy the module or restart the server.
|