Stockage de journaux de transaction dans une base de données relationnelle

Vous pouvez choisir de stocker vos journaux de transaction Liberty dans une base de données relationnelle plutôt que sous forme de fichiers du système d'exploitation. Cette fonction offre une prise en charge de haute disponibilité sans nécessiter de système de fichiers partagé. Le stockage de journaux du service de transaction dans une base de données relationnelle est pris en charge pour une utilisation dans un environnement de production.

Pourquoi et quand exécuter cette tâche

Le service de transaction WebSphere Application Server écrit des informations dans un journal des transactions pour chaque transaction globale qui implique au moins deux ressources, 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 consignées dans les journaux des transactions lors de la phase de préparation d'une transaction répartie, de sorte que si un serveur avec des transactions actives redémarre après une défaillance, le service de transaction peut utiliser les journaux pour relecture des transactions dont le statut est équivoque. Cela permet de remettre le système dans un état cohérent.

La configuration par défaut consiste à stocker des journaux de transactions en tant que fichiers de système d'exploitation. Cette prise en charge de transactions haute disponibilité nécessite d'utiliser un système de fichiers partagé pour héberger les journaux de transactions, comme un stockage en réseau NAS ou SAN monté sur NFSv4.

Mais, vous pouvez choisir de stocker les journaux de transactions dans un système de gestion de base de données relationnelle. Cette option de configuration est destinée aux utilisateurs opérant dans un environnement à haute disponibilité (HA). Cette fonction permet aux clients, et particulièrement à ceux ayant investi dans la technologie de base de données à haute disponibilité, d'utiliser, comme alternative à un système de fichiers partagé, leur base de données à haute disponibilité en tant que référentiel partagé pour les journaux de transactions. Vous pouvez utiliser tout type de base de données pris en charge par Liberty.

Vous pouvez configurer un serveur d'applications pour récupérer les journaux d'un autre serveur d'applications. Le serveur d'applications propriétaire d'origine ne doit pas être en cours d'exécution lorsque cette procédure est utilisée. Celle-ci est généralement employée pour effectuer une reprise transactionnelle restante lorsque les journaux du service de transaction sont disponibles et que le serveur d'applications propriétaire d'origine ne peut pas être démarré.

Le principe de reprise pour Liberty est le même que pour WebSphere Application Server Traditional. Pour plus d'informations sur la reprise, reportez-vous aux ressources suivantes :

A faire : Ne configurez pas des serveurs d'applications pour qu'ils utilisent les mêmes tables. En effet, cela pourrait entraîner des problèmes d'intégrité des données et d'altération de journal. Si un suffixe est spécifié, il est directement ajouté à la fois au nom de la table et à l'index.

Procédure

Pour configurer les journaux de transactions Liberty de sorte qu'ils soient stockées dans un SGBD relationnel, procédez comme suit :

  1. Configurez une source de données non transactionnelle, dédiée, dans le fichier server.xml Liberty.
    L'exemple suivant extrait du fichier server.xml illustre la manière de configurer Liberty pour stocker ses journaux de transaction dans une base de données DB2 :
    <transaction> 
      <dataSource transactional="false">
        <jdbcDriver libraryRef="DB2JCC4LIB"/>
        <properties.db2.jcc currentSchema="CBIVP"
          databaseName="SAMPLE" driverType="4"
          portNumber="50000" serverName="localhost" 
          user="db2admin" password="{xor}Oz1tPjsyNjE=" />
      </dataSource> 
    </transaction> 
    
    <library id="DB2JCC4LIB">
      <fileset dir="C:/SQLLIB/java" includes="db2jcc4.jar db2jcc_license_cu.jar"/>
    </library>
  2. Facultatif : Créez les tables de base de données.

    Liberty tente de créer les tables de base de données nécessaires au premier démarrage du serveur. S'il n'est pas possible de les créer, par exemple en raison d'autorisations insuffisantes, le démarrage du serveur échoue. Dans ces circonstances, vous devez créer les deux tables de bases de données manuellement.

    Le stockage de journaux de transactions dans un système de gestion de base de données relationnelle pour un serveur d'applications nécessite que chaque serveur possède ses propres tables. Pour une configuration WebSphere Application Server Traditional, spécifiez un suffixe de table dans l'URL personnalisée qui est unique pour chaque serveur d'applications. Le document WebSphere Application Server: Storing transaction and compensation logs in a relational database for high availability concerne le produit traditionnel, mais présente la création du suffixe et des noms de table. Dans Liberty, le suffixe est spécifié à l'aide de l'attribut transactionLogDBTableSuffix d'élément de transaction. Pour plus d'informations sur transactionLogDBTableSuffix, reportez-vous à la rubrique Transaction Manager (transaction).

    Les structures DDL suivantes présentent comment créer les tables dans DB2 :
    CREATE TABLE WAS_TRAN_LOG(
      SERVER_NAME VARCHAR(128),
      SERVICE_ID SMALLINT,
      RU_ID BIGINT,
      RUSECTION_ID BIGINT,
      RUSECTION_DATA_INDEX SMALLINT,
      DATA BLOB) 
    CREATE TABLE WAS_PARTNER_LOG(
      SERVER_NAME VARCHAR(128),
      SERVICE_ID SMALLINT,
      RU_ID BIGINT,
      RUSECTION_ID BIGINT,
      RUSECTION_DATA_INDEX SMALLINT,
      DATA BLOB) 
    Les structures DDL suivantes montrent comment créer les tables dans l'ancienne version de DB2 :
    CREATE TABLE WAS_TRAN_LOG(
      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_LOG(
      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 montrent comment créer des index pour ces tables :
    CREATE INDEX IXWSTRAN_LOG ON WAS_TRAN_LOG (RU_ID ASC, SERVICE_ID ASC, SERVER_NAME ASC)
    CREATE INDEX IXWSPARTNER_LOG ON WAS_PARTNER_LOG (RU_ID ASC, SERVICE_ID ASC, SERVER_NAME ASC)
    Les structures DDL suivantes illustrent la création de la table de base de données sous Oracle :
    CREATE TABLE WAS_TRAN_LOG(
      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_LOG(
      SERVER_NAME VARCHAR(128),
      SERVICE_ID SMALLINT,
      RU_ID NUMBER(19),
      RUSECTION_ID NUMBER(19),
      RUSECTION_DATA_INDEX SMALLINT,
      DATA BLOB)

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

Nom du fichier : twlp_store_logs_in_rdb.html