[IBM i][AIX Solaris HP-UX Linux Windows]

Stockage de journaux de transaction et de compensation dans une base de données relationnelle pour haute disponibilité

Vous pouvez stocker les journaux de transaction et de compensation WebSphere Application Server dans une base de données relationnelle plutôt que sous forme de fichiers de système d'exploitation. Cette fonction offre une prise en charge de haute disponibilité sans nécessiter de système de fichiers partagé.

Pourquoi et quand exécuter cette tâche

Le service de transaction WebSphere Application Server transaction service écrit des informations dans le journal des transactions pour chaque transaction globale qui implique deux ressources ou plus, ou qui est répartie sur plusieurs serveurs. Ces transactions sont lancées ou arrêtées par leurs applications ou par le conteneur dans lequel elles sont déployées. Afin d'assurer l'intégrité des journaux, ces derniers sont gérés par le service de transaction. Les informations sont écrites dans les journaux de transaction lors de la phase de préparation d'une transaction répartie. Si un serveur d'applications WebSphere avec des transactions actives redémarre après un incident, le service de transaction peut utiliser les journaux pour réexécuter les transactions en attente de validation. Ce niveau d'intégrité permet de ramener l'ensemble du système à un état cohérent.

Dans les versions précédentes de WebSphere Application Server, les journaux de transaction étaient stockés sous forme de fichiers de système d'exploitation. Dans WebSphere Application Server versions 8.5.5 et ultérieures, cette configuration reste la configuration par défaut. Vous pouvez également choisir de stocker les journaux de transactions dans une base de données relationnelle. Cette option de configuration est principalement utilisée dans les environnements à haute disponibilité. De plus, dans les éditions précédentes de WebSphere Application Server, la prise en charge des transactions à haute disponibilité nécessitait l'utilisation d'un système de fichiers partagé pour héberger les journaux de transactions, par exemple un réseau de stockage d'entreprise monté NFSv4 ou un réseau d'unités de stockage. Cette nouvelle fonction vous permet, en particulier si vous avez investi dans la technologie de base de données à haute disponibilité, d'utiliser votre base de données à haute disponibilité au lieu d'un système de fichiers partagé comme référentiel partagé pour les journaux de transactions.

Remarque : L'implémentation actuelle du stockage des journaux de transactions et de compensation dans une base de données relationnelle prend en charge les fonctions à haute disponibilité dans DB2 et Oracle. Par exemple, les fonctions propres au client, telles que la fonction de reprise à haut niveau de disponibilité après incident de DB2 ou Oracle RAC DataGuard, qui permet la reconnexion à une autre instance de base de données en cas d'incident, sont prises en charge. Les fonctions de haute disponibilité dans les bases de données relationnelles des autres fournisseurs ne sont à l'heure actuelle pas prises en charge.

Dans l'implémentation actuelle, si des exceptions JDBC inattendues sont générées par la fonction de journal de reprise centrale, la journalisation des transactions est désactivée et le serveur doit être arrêté de manière à permettre la reprise des transactions en cours. Aucune tentative de reconnexion n'est effectuée tant que le serveur n'est pas redémarré et l'implémentation actuelle n'essaie pas de déterminer si la condition est transitoire.

Dans WebSphere Application Server versions 8.5.5 et ultérieures, vous pouvez utiliser une fonction similaire, également destinée aux clients qui travaillent dans un environnement à haute disponibilité, afin de stocker les journaux de reprise de compensation dans une base de documents relationnelle. Le service de compensation de WebSphere Application Server permet aux applications se trouvant sur des systèmes distincts de coordonner des activités qui sont associées plus librement que des transactions atomiques. Ce service stocke dans ses propres journaux de reprise dédiés les informations requises pour effectuer une compensation après un incident système.

Eviter les incidents Eviter les incidents: La taille maximale de pool pour la source de données du journal de reprise SQL est la suivante :
(2 * nombre de serveurs potentiellement en cours de reprise homologue) + 2
Cette taille maximale de pool permet à un nombre suffisant de connexions à la base de données de fermer tous les journaux de transactions connexes. Si cette valeur n'est pas définie pour la taille maximale de pool, le message d'erreur J2CA0045E peut s'afficher, car le nombre de connexions disponibles n'est pas suffisant.gotcha

Procédure

Vous devez configurer l'emplacement du journal de transactions et l'emplacement du journal de compensation pour chaque serveur du cluster avant d'activer la haute disponibilité ; pour ce faire, définissez les attributs TransactionLogDirectory et CompensationLogDirectory pour chaque serveur. Chaque serveur d'un cluster doit faire référence à des emplacements de journal de transactions et de journal de compensation uniques au moyen d'une propriété tablesuffix distincte, pour éviter que plusieurs serveurs ne tentent d'accéder aux mêmes ressources du système de gestion de base de données relationnelle. Par exemple, si vous disposez d'un cluster nommé AppCluster comportant les quatre serveurs suivants :
  • AppClusterMember1
  • AppClusterMember2
  • AppClusterMember3
  • AppClusterMember4
Vous pouvez définir les suffixes de table suivants pour AppCluster :
  • App1 pour AppClusterMember1
  • App2 pour AppClusterMember2
  • App3 pour AppClusterMember3
  • App4 pour AppClusterMember4

Effectuez les étapes suivantes :

  1. Configurez une source de données non transactionnelle pour le stockage des journaux de reprise de transaction et de compensation :
    1. Créez un fournisseur JDBC pour votre implémentation de système de gestion de base de données relationnelle. Spécifiez un type d'implémentation non XA.
    2. Créez un alias de données d'authentification JAAS J2C. Cet alias de données définit les données d'identification de sécurité utilisées pour la connexion au système de gestion de base de données relationnelle. Les données d'identification qui sont définies dans le système de gestion de base de données relationnelle doivent posséder les droits suffisants pour créer des tables dans la base de données.
    3. Créez une source de données en utilisant le fournisseur JDBC créé à l'étape a. Son alias d'authentification géré par le composant doit correspondre à l'alias JAAS créé à l'étape b. Définissez l'URL afin que votre source de données spécifie une connexion au système de gestion de base de données relationnelle.
    4. Configurez la nouvelle source de données de sorte qu'elle soit non transactionnelle en effectuant les étapes suivantes :
      1. Ouvrez la nouvelle source de données.
      2. Sous Propriétés supplémentaires, cliquez sur Propriétés de la source de données WebSphere Application Server.
      3. Cochez la case Source de données non transactionnelle.
      4. Enregistrez les modifications.
  2. Configurez le service de transaction afin que les transactions soient stockées dans une base de données relationnelle :
    1. Dans la console d'administration WebSphere Application Server, cliquez sur Serveurs > Types de serveurs > Serveurs d'applications WebSphere > nom_serveur. Les propriétés du serveur d'applications spécifié sont affichées.
    2. Dans la section Paramètres du conteneur, cliquez sur Services du conteneur > Service Transaction. La page Paramètres du service de transaction s'affiche.
    3. Sélectionnez l'onglet Configuration s'il n'est pas déjà affiché.
    4. Dans le champ Répertoire du journal des transactions, entrez une chaîne pour indiquer que vous voulez que les journaux soient stockés dans une base de données. Cette chaîne doit respecter le format suivant :
      custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=nom_JNDI_source_de_données,tablesuffix=suffixe
      nom_JNDI_source_de_données correspond au nom JNDI de la source de données non transactionnelle créée précédemment et suffixe, à la chaîne qui permet d'identifier de manière unique chaque membre de votre cluster haute disponibilité.
      Restriction : Si vous utilisez une base de données Oracle, la longueur du suffixe ne doit pas dépasser 15 caractères.
  3. (Facultatif) Configurez le service de compensation afin que les transactions soient stockées dans une base de données relationnelle si vous prévoyez d'utiliser des services de compensation ou d'activité dans WebSphere Application Server :
    1. Dans la console d'administration WebSphere Application Server, cliquez sur Serveurs > Types de serveurs > Serveurs d'applications WebSphere > nom_serveur. Les propriétés du serveur d'applications spécifié sont affichées.
    2. Dans la section Paramètres du conteneur, cliquez sur Services du conteneur > Service de compensation. La page Paramètres du service de compensation s'affiche.
    3. Sélectionnez l'onglet Configuration s'il n'est pas déjà affiché.
    4. Dans le champ Répertoire des journaux de reprise, entrez une chaîne pour indiquer que vous voulez que les journaux soient stockés dans une base de données. Cette chaîne doit respecter le format suivant :
      custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=nom_JNDI_source_de_données,tablesuffix=suffixe
      nom_JNDI_source_de_données correspond au nom JNDI de la source de données non transactionnelle créée précédemment et suffixe, à la chaîne qui permet d'identifier de manière unique chaque membre de votre cluster haute disponibilité.
      Restriction : Si vous utilisez une base de données Oracle, la longueur du suffixe ne doit pas dépasser 15 caractères.
  4. (Facultatif) Créez les tables de base de données.

    WebSphere Application Server tente de créer les tables de base de données nécessaires lors de son premier démarrage. Lorsque cette opération de création n'est pas possible, par exemple parce que l'autorisation est insuffisante, le serveur ne démarre pas. Dans ce cas, vous devez créer manuellement les trois tables de base de données nécessaires.

    Le fichier DDL suivant est représentatif et approprié pour un environnement de serveur autonome: Dans un environnement autonome, deux tables de base de données, une table de journaux de transactions et une table de journaux de partenaire, sont nécessaires pour permettre la prise en charge du service Transactions. Si vous prévoyez d'utiliser les services de compensation ou d'activité, une troisième table de journaux de compensation est également nécessaire.

    Les noms de table peuvent être personnalisés en fonction de votre environnement. Par exemple, vous devez créer quatre tables de journaux de transactions, quatre tables de journaux de partenaire et éventuellement quatre tables de journaux de compensation si vous disposez d'un cluster nommé AppCluster comportant les quatre serveurs suivants :
    • AppClusterMember1
    • AppClusterMember2
    • AppClusterMember3
    • AppClusterMember4
    Par conséquent, vous pouvez définir les tables suivantes pour AppCluster :
    Nom du cluster Nom du serveur Table de journaux de transactions Table de journaux de partenaire Table de journaux de compensation
    AppCluster AppClusterMember1 WAS_TRAN_LOGApp1 WAS_PARTNER_LOGApp1 WAS_COMP_LOGApp1
      AppClusterMember2 WAS_TRAN_LOGApp2 WAS_PARTNER_LOGApp2 WAS_COMP_LOGApp2
      AppClusterMember3 WAS_TRAN_LOGApp3 WAS_PARTNER_LOGApp3 WAS_COMP_LOGApp3
      AppClusterMember4 WAS_TRAN_LOGApp4 WAS_PARTNER_LOGApp4 WAS_COMP_LOGApp4
    Le fichier DDL suivant illustre la création des tables de base de données avec le suffixe de table App1 sous DB2 :
    CREATE TABLE WAS_TRAN_LOGApp1(
      SERVER_NAME VARCHAR(128),
      SERVICE_ID SMALLINT,
      RU_ID BIGINT,
      RUSECTION_ID BIGINT,
      RUSECTION_DATA_INDEX SMALLINT,
      DATA LONG VARCHAR FOR BIT DATA) 
    CREATE TABLE WAS_PARTNER_LOGApp1(
      SERVER_NAME VARCHAR(128),
      SERVICE_ID SMALLINT,
      RU_ID BIGINT,
      RUSECTION_ID BIGINT,
      RUSECTION_DATA_INDEX SMALLINT,
      DATA LONG VARCHAR FOR BIT DATA) 
    CREATE TABLE WAS_COMP_LOGApp1(
      SERVER_NAME VARCHAR(128),
      SERVICE_ID SMALLINT,
      RU_ID BIGINT,
      RUSECTION_ID BIGINT,
      RUSECTION_DATA_INDEX SMALLINT,
      DATA LONG VARCHAR FOR BIT DATA) 
    Les structures DDL suivantes illustrent la création de la table de base de données sous Oracle :
    CREATE TABLE WAS_TRAN_LOGApp1(
      SERVER_NAME VARCHAR(128),
      SERVICE_ID SMALLINT,
      RU_ID NUMBER(19),
      RUSECTION_ID NUMBER(19),
      RUSECTION_DATA_INDEX SMALLINT,
      DATA BLOB)
    CREATE TABLE WAS_PARTNER_LOGApp1(
      SERVER_NAME VARCHAR(128),
      SERVICE_ID SMALLINT,
      RU_ID NUMBER(19),
      RUSECTION_ID NUMBER(19),
      RUSECTION_DATA_INDEX SMALLINT,
      DATA BLOB)
    CREATE TABLE WAS_COMP_LOGApp1(
      SERVER_NAME VARCHAR(128),
      SERVICE_ID SMALLINT,
      RU_ID NUMBER(19),
      RUSECTION_ID NUMBER(19),
      RUSECTION_DATA_INDEX SMALLINT,
      DATA BLOB)

Exemple

Si vous disposez d'un cluster nommé AppCluster comportant les quatre serveurs AppClusterMember1, AppClusterMember2, AppClusterMember3 et AppClusterMember4, configurez les emplacements de journaux comme suit :
Nom du cluster Nom du serveur Table de journaux de transactions Table de journaux de compensation
AppCluster AppClusterMember1 custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App1 custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App1
AppClusterMember2 custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App2 custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App2
AppClusterMember3 custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App3 custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App3
AppClusterMember4 custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App4 custom://com.ibm.rls.jdbc.SQLRecoveryLog?datasource=jdbc/tranlog,tablesuffix=App4
Dans cet exemple, le suffixe de table est défini comme suit :
  • AppClusterMember1
  • AppClusterMember2
  • AppClusterMember3
  • AppClusterMember4
Des tables de base de données portant les noms suivants sont créées :
  • WAS_TRAN_LOGApp1
  • WAS_TRAN_LOGApp2
  • WAS_TRAN_LOGApp3
  • WAS_TRAN_LOGApp4
  • WAS_PARTNER_LOGApp1
  • WAS_PARTNER_LOGApp2
  • WAS_PARTNER_LOGApp3
  • WAS_PARTNER_LOGApp4
  • WAS_COMP_LOGApp1
  • WAS_COMP_LOGApp2
  • WAS_COMP_LOGApp3
  • WAS_COMP_LOGApp4

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=tjta_store_logs_in_rdb
Nom du fichier : tjta_store_logs_in_rdb.html