Restoring a data store and recovering its messaging engine

When a failure occurs that cannot be dealt with by the system, you can restore the data store or data stores from a backup. Use this task to restore a backup of a data store and to recover its associated messaging engine afterward.

About this task

You should also restore the configuration files for the system, to ensure that it functions as it did at the time the backup was taken, for more information about why you should do this see Service integration backup. After you have restored the data store, you must restart the associated messaging engine.

When you restart a messaging engine after restoring a backup you must start it in Restart after restore mode, to minimize the effects of the messaging engine not being synchronized with any other messaging engines it was in communication with before the failure. If you restart the messaging engine in Normal mode, some of the new messages produced at this messaging engine might be discarded by the receiving messaging engine, for an indeterminate amount of time after restart. In Restart after restore mode, previously transmitted messages might be resent, potentially creating duplicates of messages that were produced before the backup was taken. However new messages are not lost or duplicated (if this is specified by the quality of service for the message).

You can restart a messaging engine in Restart after restore mode only by using the wsadmin client; you cannot do it from the administrative console. You must only start a messaging engine in this mode when starting the messaging engine for the first time after restoring the backup. After the initial restart, you can undertake further restarts as usual.

Restart after restore mode is ignored if you start the server in Recovery mode. If you require both a Recovery mode start and a Restart after restore mode start:

1. Start the server in recovery mode
2. Wait for the startup to complete and for the server to stop
3. Start the messaging engine in Restart after restore mode

If you see the following message in the JVM System output fileSystemOut.log, it might indicate that you have restored from a backup and restarted the messaging engine without using the Restart after restore mode.

CWSIP0784E: Messaging engine: receivingME received a message from 
messaging engine: producingME that was not expected.

To resolve this issue, stop the messaging engine and restart it in Restart after restore mode.

Note: This message might also appear in other situations, so you should restart the messaging engine in Restart after restore mode only if you know you have restored a backup.

For information about the JVM System output fileSystemOut.log and how to view it, see Viewing JVM logs.

Note: This topic references one or more of the application server log files. As a recommended alternative, you can configure the server to use the High Performance Extensible Logging (HPEL) log and trace infrastructure instead of using SystemOut.log , SystemErr.log, trace.log, and activity.log files on distributed and IBM® i systems. You can also use HPEL in conjunction with your native z/OS® logging facilities. If you are using HPEL, you can access all of your log and trace information using the LogViewer command-line tool from your server profile bin directory. See the information about using HPEL to troubleshoot applications for more information on using HPEL.

You can recover any number of messaging engines at the same time, by following the actions given for each messaging engine in turn.

1. Change the initial state of the messaging engine to Stop, so that the messaging engine will not be automatically restarted by a server process:
   1. Use the administrative console to select the messaging engine by clicking Service integration -> Buses -> bus_name -> [Topology] Messaging engines -> engine_name.
   2. In the Initial state list, click Stopped.
   3. Click OK.
2. Save your changes to the master configuration, ensuring that you select the Synchronize changes with Nodes check box.
3. Stop the messaging engine if it is running (see Stopping a messaging engine for instructions on how to do this). If the messaging engine does not respond, stop the server process that is hosting the messaging engine.
4. Restore the backup of the data store that is accessed by the messaging engine, by referring to Restoring a data store.
5. Restore the backup of the configuration files by using the backupConfig command (see Backing up and restoring administrative configuration files). This backup should have been taken at the same time as the data store backup.
6. Restart any servers that were stopped by the failure.
7. Restart the messaging engine in Restart after restore mode by performing the following steps:
   1. Start the wsadmin client.
      Note: The wsadmin scripting client is run from Qshell. For more information, see Configuring Qshell to run WebSphere scripts using wsadmin scripting.

      For more information about the wsadmin client, see wsadmin scripting tool.

   2. Invoke the start command, with the FLUSH parameter, on the MBean for the messaging engine. For example:

      wsadmin>myME=AdminControl.queryNames("type=SIBMessagingEngine,*").splitlines()[0]
      wsadmin>AdminControl.invoke(myME , "state")
      'stopped'
      wsadmin>AdminControl.invoke(myME , 'start' , ["FLUSH"])
      wsadmin>AdminControl.invoke(myME , "state")
      'started'

   A number of messages might be output to the JVM SystemOut.log file to indicate the progress of the restart process.
8. Check the JVM SystemOut.log file for the following message that indicates that the restart was successful, in other words, no failures occurred while attempting to restart the messaging engine.

   CWSIP0783E: Messaging engine: messagingEngine started,
   flush of all delivery streams completed.

   If this message does not appear, a failure has occurred that has prevented the messaging engine from restarting. Resolve the cause of the failure and repeat the Restart after restore procedure until the restart is successful.