Restauration d'un magasin de données et récupération de son moteur de messagerie

Lorsqu'un incident ne pouvant pas être résolu par le système survient, vous pouvez restaurer le ou les magasins de données d'une sauvegarde. Cette tâche permet de restaurer une sauvegarde d'un magasin de données et de récupérer le moteur de messagerie associé.

Pourquoi et quand exécuter cette tâche

Vous pouvez également restaurer les fichiers de configuration du système pour que le système fonctionne de la même manière qu'au moment de la sauvegarde. Pour plus d'informations sur l'intérêt de cette opération, voir Sauvegarde de l'intégration de services. Une fois que vous avez restauré le magasin de données, vous devez redémarrer le moteur de messagerie associé.

Lorsque vous redémarrez un moteur de messagerie après avoir restauré une sauvegarde, vous devez le démarrer en mode Redémarrage après restauration, afin de minimiser les effets de l'absence de synchronisation du moteur de messagerie avec tout autre moteur de messagerie avec lequel il communiquait avant la défaillance. Si vous redémarrez le moteur de messagerie en mode Normal, il se peut que certains des nouveaux messages générés sur ce moteur de messagerie soient ignorés par le moteur de messagerie récepteur pendant une durée indéterminée après le redémarrage. En mode Redémarrage après restauration, les messages déjà transmis peuvent être renvoyés, ce qui peut créer des doublons des messages générés avant la sauvegarde. Toutefois, les nouveaux messages ne sont pas perdus ni dupliqués (si cela est spécifié par la qualité de service du message).

Vous ne pouvez redémarrer un moteur de messagerie en mode Redémarrage après restauration qu'à l'aide du client wsadmin ; cette opération n'est pas possible à partir de la console d'administration. Vous ne devez démarrer un moteur de messagerie dans ce mode qu'au premier démarrage après la restauration de la sauvegarde. Après le redémarrage initial, restart, les redémarrages qui suivent peuvent être effectués de manière habituelle.

Le mode Redémarrage après restauration est ignoré lors du démarrage du serveur en mode Reprise. Si un démarrage en mode Reprise et un démarrage en mode Redémarrage après restauration sont requis :

  1. démarrez le serveur en mode Reprise,
  2. attendez que le démarrage aboutisse et que le serveur s'arrête,
  3. démarrez le moteur de messagerie en mode Redémarrage après restauration.
Si le message suivant s'affiche dans le fichier de sortie système de la JVM [AIX Solaris HP-UX Linux Windows]SystemOut.log, cela peut signifier que vous avez procédé à une restauration à partir d'une sauvegarde et que vous avez redémarré le moteur de messagerie sans utiliser le mode Redémarrage après restauration.
CWSIP0784E: Le moteur de messagerie : MErécepteur a reçu un message inattendu du 
moteur de messagerie : MEproducteur.
Pour résoudre cet incident, arrêtez le moteur de messagerie et redémarrez-le en mode Redémarrage après restauration.
Remarque : Ce message peut également s'afficher dans d'autres situations. Vous ne devriez donc redémarrer le moteur de messagerie en mode Redémarrage après restauration que si vous savez que vous avez restauré une sauvegarde.
Pour plus d'informations sur le fichier de sortie système JVM [AIX Solaris HP-UX Linux Windows]SystemOut.log et sur l'affichage de ce dernier, voir Affichage des journaux JVM.
Remarque : Cette rubrique fait référence à un ou plusieurs des fichiers journaux de serveur d'applications. Il est recommandé de configurer le serveur de telle sorte qu'il utilise l'infrastructure de journalisation et de trace HPEL (High Performance Extensible Logging) à la place des fichiers SystemOut.log, SystemErr.log, trace.log et activity.log sur les systèmes distribués et IBM® i. Vous pouvez également utiliser HPEL conjointement avec vos fonctions de journalisation z/OS natives. Si vous utilisez l'infrastructure HPEL, vous pouvez accéder à toutes les informations de journalisation et de trace en utilisant l'outil de ligne de commande LogViewer à partir de votre répertoire bin de profil de serveur. Pour plus d'informations sur l'utilisation de HPEL, voir les informations sur l'utilisation de HPEL en vue du traitement des incidents liés aux applications.

Vous pouvez restaurer simultanément plusieurs moteurs de messagerie en effectuant les opérations indiquées pour chaque moteur de messagerie.

Procédure

  1. Remplacez l'état initial du moteur de messagerie par Arrêt, pour qu'il ne soit pas automatiquement redémarré par un processus serveur :
    1. Dans la console d'administration, sélectionnez le moteur de messagerie en cliquant sur Intégration des services -> Bus -> nom_bus -> [Topologie] Moteurs de messagerie -> nom_moteur.
    2. Dans la liste Etat initial, cliquez sur Arrêté.
    3. Cliquez sur OK.
  2. Sauvegardez vos modifications dans la configuration maîtresse en vous assurant que vous avez coché Synchroniser les modifications avec les noeuds.
  3. Arrêtez le moteur de messagerie s'il est actif (voir Arrêt d'un moteur de messagerie pour les instructions correspondantes). Si le moteur de messagerie ne répond pas, arrêtez le processus serveur qui l'héberge.
  4. Restaurez la sauvegarde du magasin de données auquel le moteur de messagerie accède (voir Restauration d'un magasin de données).
  5. Restaurez la sauvegarde des fichiers de configuration en utilisant la commande backupConfig (voir Backing up and restoring administrative configuration files). Cette sauvegarde doit avoir été effectuée en même temps que celle du magasin de données.
  6. Redémarrez les serveurs arrêtés en raison de la défaillance.
  7. Redémarrez le moteur de messagerie en mode Redémarrage après restauration de la manière suivante :
    1. Démarrez le client wsadmin.
      [IBM i]Remarque : [IBM i]Le client de scriptage wsadmin est exécuté à partir de Qshell. [IBM i]Pour plus d'informations, voir Configuration de Qshell pour exécuter des scripts WebSphere à l'aide de l'outil de scriptage wsadmin.

      Pour plus d'informations sur le client wsadmin, voir Outil de scriptage wsadmin.

    2. Appelez la commande start avec le paramètre FLUSH dans le MBean du moteur de messagerie. Par exemple :
      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'
    Un certain nombre de messages peuvent être générés dans le fichier SystemOut.log de la JVM pour indiquer la progression du processus de redémarrage.
  8. Recherchez dans le fichier JVM SystemOut.log le message ci-après indiquant que le redémarrage a abouti, c'est-à-dire qu'aucun incident n'est survenu lors de la tentative de redémarrage du moteur de messagerie
    CWSIP0783E: Le moteur de messagerie : moteurMessagerie a démarré, vidage de tous les flux de livraison terminé.
    Si ce message n'apparaît pas, cela signifie qu'un incident a empêché le moteur de messagerie de redémarrer. Résolvez cet incident et répétez la procédure de redémarrage après restauration jusqu'à ce que le redémarrage aboutisse.

Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tjm0200_
Nom du fichier : tjm0200_.html