Migratable Target: Configuration: Migration

This page allows you to configure a migratable target, including specifying a preferred host server in the cluster and selecting candidate servers to use as a backup for services on this migratable target. For automatic service migration, you need to select the appropriate automatic migration policy. You can also optionally provide the appropriate pre-migration and post-migration scripts to move a persistent store's data across migrated servers. There are also options to have a migratable target with a failed service deactivated and reactivated in place, instead of being migrated.

Name	Description
Name	The name of this migratable target. MBean Attribute: `MigratableTargetMBean.Name` Changes take effect after you redeploy the module or restart the server.
Service Migration Policy	Defines the type of migration policy to use for the services hosted by this migratable target. Valid options are: `Manual Service Migration Only` Indicates that no automatic migration of services hosted by this migratable target will occur. `Auto-Migrate Exactly-Once Services` Indicates that if at least one Managed Server in the candidate server list is running, the services hosted by this migratable target will be active somewhere in the cluster if servers should fail or are administratively shut down (either gracefully or forcibly). For example, it is a recommended best practice to use this policy when a migratable target hosts a path service, so if its preferred server fails or is shut down, the path service will automatically migrate to another candidate server, and so will always be active in the cluster. Note This value can lead to target grouping on a server member. For example, if you have five exactly-once migratable targets and only one Managed Server is started in the cluster, then all five targets will be activated on that server. `Auto-Migrate Failure-Recovery Services` Indicates that the services hosted by this migratable target will only start if the migratable target's User Preferred Server (UPS) is started. If an administrator manually shuts down the UPS, either gracefully or forcibly, then a failure-recovery service will not migrate. However, if the UPS fails due to an internal error, then the service will be migrated to another candidate server. If such a candidate server is unavailable (due to either a manual shutdown or an internal failure), then the migration framework will first attempt to reactivate the service on its UPS server. If the UPS server is not available at that time, then the service will be migrated to another candidate server. MBean Attribute: `MigratableTargetMBean.MigrationPolicy` Changes take effect after you redeploy the module or restart the server.
User-Preferred Server	The server member in the cluster that you prefer the migratable target to be active on. MBean Attribute: `MigratableTargetMBean.UserPreferredServer`
Constrained Candidate Servers	Select server members in the cluster to use as a backup for services on this migratable target.
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 `MIDDLEWARE_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 `MIDDLEWARE_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 script will run. Specifying 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	Specifies 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	Specifies whether or not the post-deactivation script is allowed to run on a different machine. Normally, when auto migration 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.
Restart On Failure	Specifies whether or not a failed service will first be deactivated and reactivated in place, instead of being migrated. The number of restart attempts is controlled by NumberOfRestartAttempts . Once these restart attempts are exhausted, the service will migrate. A restarting migratable target will deactivate all services on it in order, then reactivate them all. MBean Attribute: `MigratableTargetMBean.RestartOnFailure` Changes take effect after you redeploy the module or restart the server.
Seconds Between Restarts	Specifies how many seconds to wait in between attempts to restart the failed service. MBean Attribute: `MigratableTargetMBean.SecondsBetweenRestarts` Changes take effect after you redeploy the module or restart the server.
Number Of Restart Attempts	Specifies how many restart attempts to make before migrating the failed service. Note that these are consecutive attempts. If the value is set to 6, and the service restart fails 5 times before succeeding, but then fails again later, it will not instantly migrate. Each failure gets its own count of restart attempts. A value of 0 is identical to setting RestartOnFailure to false. A value of -1 indicates the service shouldnever be migrated; instead, it will be restarted until it either works or the server shuts down. MBean Attribute: `MigratableTargetMBean.NumberOfRestartAttempts` Changes take effect after you redeploy the module or restart the server.

Administration Console Online Help

Migratable Target: Configuration: Migration

Configuration Options