![[IBM i]](../images/iseries.gif)
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
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.
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.

(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.gotchaProcédure
- AppClusterMember1
- AppClusterMember2
- AppClusterMember3
- AppClusterMember4
- App1 pour AppClusterMember1
- App2 pour AppClusterMember2
- App3 pour AppClusterMember3
- App4 pour AppClusterMember4
Effectuez les étapes suivantes :
Exemple
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 |
- AppClusterMember1
- AppClusterMember2
- AppClusterMember3
- AppClusterMember4
- 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