When you configure service migration for dynamic clusters, you select a Service Migration Policy for each persistent store. This topic provides guidelines and considerations when you select the Service Migration Policy. The following options are available:

1. Log in to the Administration Console, if you have not already done so, and click Lock & Edit.
2. In the Domain Structure pane, expand Environment, expand Services, and then select Persistent Stores.
3. Click the name of the Persistent Store that you want to modify.

   Note:

   When you use JDBC persistent stores, additional unused File Stores are automatically created but are not targeted to your clusters. Ignore these File Stores.

4. Click the High Availability tab.
5. From the Migration Policy drop-down menu, select the appropriate policy for the cluster. See About Selecting a Service Migration Policy for Dynamic Clusters.
6. Click Save.
7. Repeat steps 2 through 6 for each additional persistent store in the cluster.
8. Click Activate Changes.
9. Restart the managed servers for the changes to be effective. If you are configuring other aspects of service migration in the same configuration change session, you can use a final unique restart to reduce downtime.

1. Log in to the FMW Control Console by accessing ADMINVHN:7001/em and by using the required credentials.
2. Click the lock icon on the upper right corner and click Lock & Edit.
3. On the target navigation tree on the left, select the relevant domain.
4. Click Weblogic Domain > Environment > Server templates.
5. Click the relevant template and then, click the Migration tab.
6. From the JTA Migration Policy drop-down list, select the required migration policy for the service. The settings required for each SOA component is as follows. (Some may not be shown, depending on what has been installed.):

   • SOA_Cluster: Failure Recovery

   • OSB_Cluster: Failure Recovery

   • MFT_Cluster: Failure Recovery

7. Click Save.
8. Click the lock icon on the upper right corner and click Activate Changes.
9. Restart the managed servers and the Administration Server for the changes to be effective.

1. Log in to the Administration Console, if you have not already done so.
2. In the Domain Structure pane, select Environment, and then Clusters.
3. Click in the cluster where you want to verify the service migration.
4. Click the Monitoring tab, then Health.
   The console displays a list of the servers of the cluster and their state.
5. Expand each managed server and verify that its persistent stores are okay.
6. In Domain Structure pane, select Environment > Services > Messaging > JMS Servers.
7. Click on one of the JMS Servers of the cluster, and then click the Monitoring tab.

   Verify that you see two instances (one per dynamic server) and each instance is running on one of the dynamic servers.

8. Use the operating system command line to stop the first Managed Server. Use the following command to end the Managed Server process and simulate a crash scenario:

   kill -9 pid

   In this example, replace pid with the process ID (PID) of the Managed Server. You can identify the PID by running the following UNIX command:

   ps -ef | grep managed_server_name

   Note:

   You can configure the Managed Server to start automatically after you initially end the process. In this case, you must end the second process by using the kill –9 command again.

9. Watch the terminal window (or console) where the Node Manager is running.
   You see a message indicating that the selected Managed Server has failed. The message appears as follows:

   <INFO> <domain_name> <server_name>
   <The server 'server_name' with process id 4668 is no longer alive; waiting for the process to die.>
   <INFO> <domain_name> <server_name>
   <Server failed during startup. It may be retried according to the auto restart configuration.>
   <INFO> <domain_name> <server_name>
   <Server failed but will not be restarted because the maximum number of restart attempts has been exceeded.>

10. Return to the Oracle WebLogic Server Administration Console and refresh the table of Cluster > Monitoring > Health. Verify that the persistent stores are now running in the remaining Managed Server that is still running.
11. In Domain Structure pane, select Environment > Services > Messaging > JMS Servers.
12. Click on one of the JMS Servers of the cluster, and then click the Monitoring tab.

    Verify that both the instances continue to run on the remaining Managed Server that is still running.

13. Open and review the log files for the Managed Servers that are now hosting the services. Look for any JTA or JMS errors.

    Note:

    For JMS tests, it is a good practice to get message counts from destinations and ensure that messages are not stuck in the migratable targets. For example, for uniform distributed destinations (UDDs):

    1. Access the JMS Subdeployment module in the Administration Console.

    2. In the Domain Structure pane, select Services > Messaging > JMS Modules.

    3. Click the JMS Module.

    4. In the Summary of Resources table, click Destinations, and then click the Monitoring tab. Review the Messages Total and Messages Pending values.

    Click Customize table to add these columns to the table, if these values do not appear in the table.

14. Review the logs. The messages appear as follows in the remaining server:

    <Info> <Cluster> <soahost1> <WLS_SOA1> <[STANDBY] ExecuteThread: 
    '43' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> 
    <> <49c99f17-a5d6-487d-a710-65eef0262ebc-0000063c> <1489481002608> 
    <[severity-value: 64] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-000189> 
    <The Singleton Service UMSJMSJDBCStore_auto_1_WLS_SOA2 is now active on this server.>
    
    <Info> <Cluster> <soahost1> <WLS_SOA1> <[STANDBY] ExecuteThread: 
    '43' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> 
    <> <49c99f17-a5d6-487d-a710-65eef0262ebc-0000063c> <1489481002609> 
    <[severity-value: 64] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-003130> 
    <UMSJMSJDBCStore_auto_1_WLS_SOA2 successfully activated on server WLS_SOA1.>

    For more information, you can debug with the following flags:

    -Dweblogic.debug.DebugSingletonServices=true -
    Dweblogic.debug.DebugServerMigration=true

With dynamic clustering, when a distributed instance is migrated from its preferred server, it tries to fail back when the preferred server is restarted. Therefore, after the service migration process migrates specific persistent store services to a backup server during a failover, it migrates the services back to the original server after the original server is back online.