Bases de données à haute disponibilité
Les bases de données à haute disponibilité sont hautement évolutives et se trouvent toujours sur un système de gestion de base de données relationnelle (SGBDR). Certaines restrictions s'appliquent à l'utilisation d'une base de données à haute disponibilité comme magasin de données du moteur de messagerie.
Il se peut que les bases de données possédant une structure ou une fonction de haute disponibilité comportent des serveurs principaux et de secours redondants. Si vous utilisez ce type de base de données comme magasin de données, certaines actions spécifiques sont requises :
- Assurez-vous que les bases de données principale et de secours sont identiques lorsque la base de données de secours prend le relais de la base de données principale, sauf si vous arrêtez puis redémarrez votre moteur de messagerie avant le routage des connexions vers la base de données de secours. Si les clients de base de données, tels que le moteur de messagerie, sont routés par le système depuis la base de données principale vers la base de données de secours, le moteur de messagerie suppose que les données sont identiques dans les deux bases de données.
- N'utilisez pas l'optimisation des validations à une phase, qui permet aux applications de partager les connexions JDBC utilisées par un moteur de messagerie.
Si vous utilisez la fonction HADR (High Availability Data Recovery) de DB2, veuillez tenir compte des restrictions suivantes :
- Le fournisseur de messagerie par défaut du moteur de messagerie ne prend en charge que les modes de synchronisation synchrone et quasi synchrone de la fonction HADR. Le fournisseur de messagerie par défaut ne prend pas en charge les configurations HADR asynchrones.
- La commande TAKEOVER BY FORCE n'est possible que si la base de données de secours se trouve à l'état "peer" (homologue), ou est passée de l'état "peer" à l'état actuel (par exemple l'état de déconnexion).
Si vous configurez un serveur WebSphere Application Server afin d'utiliser une base de données à haute disponibilité comme magasin de données et qu'une reprise en ligne de la base de données se produit, le serveur d'applications sur lequel le moteur de messagerie est en cours d'exécution risque de s'arrêter. Cet incident est dû au fait que le moteur de messagerie ne peut pas toujours traiter la reprise en ligne comme une erreur de communication transitoire.
Lorsque vous configurez un moteur de messagerie afin d'utiliser une base de données à haute disponibilité pour son magasin de données, assurez-vous qu'il peut redémarrer automatiquement suite à un incident de serveur d'applications. Choisissez l'option appropriée à votre configuration :
- Si vous exécutez un seul serveur, WebSphere Application Server ne propose pas de prise en charge de reprise en ligne. Pensez à d'autres sources à haute disponibilité pour cette prise en charge.
- Si vous exécutez la version WebSphere Application Server Network Deployment sans mise en cluster, la configuration par défaut de l'agent de noeud garantit un redémarrage automatique.
- Si vous exécutez la WebSphere Application Server Network Deployment avec mise en cluster, la reprise homologue redémarre le moteur de messagerie. Vérifiez que vous avez configuré la règle de haute disponibilité afin d'activer la reprise homologue.