test

Notes de version de Sun Java System Application Server Enterprise Edition 8.2

Haute disponibilité

Cette section décrit les problèmes connus de base de données haute disponibilité (HADB) et les solutions associées.

Configuration HADB à double réseau. (Aucun ID)

Sous Solaris SPARC, les bases de données HADB configurées avec double réseau fonctionnent parfaitement sur deux sous-réseaux. Cependant, du fait de problèmes au niveau du système d'exploitation ou des pilotes réseau sur certaines plates-formes matérielles, les plates-formes Solaris x86 et Linux ne gèrent pas toujours correctement les doubles réseaux. Cela crée les problèmes suivants pour la base de données HADB:

Échec de la création de la base de données HADB. (Aucun ID)

La création d'une base de données risque d'échouer en générant l'erreur suivante, indiquant que le nombre de segments de mémoire partagée disponibles est insuffisant :

HADB-E-21054: System resource is unavailable: HADB-S-05512: Attaching shared memory segment with key "xxxxx" failed, OS status=24 OS error message: Too many open files.

Solution

Vérifiez que la mémoire partagée est correctement configurée. En particulier, sous Solaris 8, inspectez le fichier /etc/system et assurez-vous que la valeur de la variable shmsys:shminfo_shmseg est au moins six fois supérieure au nombre de nœuds par hôte.

Segments de mémoire partagée bloqués et ne pouvant pas évacués. (ID 5052548)

HADB 4.3-0.16 et version ultérieure est configuré pour utiliser une mémoire partagée personnelle lorsqu'il crée et associe ses segments de mémoire partagée (avec l'indicateur SHM_SHARE_MMU). L'utilisation de cet indicateur bloque essentiellement les segments de mémoire partagée d'une mémoire physique et empêche leur évacuation. Ceci entraîne des problèmes dans des installations sur des machines bas de gamme.

Par conséquent, si un développeur dispose d'une machine dotée d'une mémoire de 512 Mo et d'espace de swap disponible et qu'il utilise Application Server7.0 EE, puis la version 7.1 EE ou ultérieure, il rencontrera des problèmes de configuration du cluster clsetup par défaut (qui crée deux nœuds HADB, chacun doté d'une devicesize de 512), ceci entraînant une RAM physique insuffisante pour prendre en charge la mémoire partagée nécessaire aux deux nœuds.

Solution

Vérifiez que vous disposez de la quantité de mémoire recommandée pour accueillir Application Server et HADB. Reportez-vous à la section Configuration requise pour HADB et plates-formes prises en charge pour plus d'informations.

La commande hadbm set ne vérifie pas la disponibilité des ressources (espace disque et mémoire). (ID 5091280)

Lorsque vous augmentez la taille des périphériques ou du tampon à l'aide de la commande hadbm set, le système de gestion vérifie la disponibilité des ressources lors de la création des bases de données ou de l'ajout de nœuds. Cependant, il ne vérifie pas si un nombre suffisant de ressources est disponible lors de la modification de la taille des périphériques ou du tampon de la mémoire principale.

Solution

Vérifiez qu'il y a suffisamment d'espace disque ou de mémoire disponible sur tous les hôtes avant d'augmenter les attributs de configuration devicesize ou buffersize.

Chemins hétérogènes pour packagepath non pris en charge. (ID 5091349)

Il est impossible d'enregistrer le même package avec le même nom à différents emplacements et sur différents hôtes ; par exemple :


hadbm registerpackage test --packagepath=/var/install1 --hosts europa11
Package successfully registered.
hadbm registerpackage test --packagepath=/var/install2 --hosts europa12
hadbm:Error 22171: A software package has already been registered with 
the package name test.

Solution

La base de données HADB ne prend pas en charge les chemins hétérogènes sur plusieurs nœuds d'un cluster de base de données. Assurez-vous que le répertoire d'installation du serveur HADB (--packagepath) est le même pour tous les hôtes concernés.

Échec de la commande createdomain possible. (ID 6173886, 6253132)

Si l'agent de gestion est exécuté sur un hôte avec plusieurs interfaces réseau, la commande createdomain risque d'échouer si toutes les interfaces réseau ne se trouvent pas sur le même sous-réseau :


hadbm:Error 22020: The management agents could not establish a 
domain, please check that the hosts can communicate with UDP multicast.

S'ils ne sont pas configurés autrement, les agents de gestion utilisent la première interface pour les multidiffusions UDP (la "première" étant déterminée par le résultat de java.net.NetworkInterface.getNetworkInterfaces() ).

Solution

La meilleure solution consiste à indiquer à l'agent de gestion quel sous-réseau utiliser (en définissant ma.server.mainternal.interfaces dans le fichier de configuration, par exemple ma.server.mainternal.interfaces=10.11.100.0). Une autre solution consiste à configurer le routeur entre les sous-réseaux de manière à acheminer les paquets multidiffusions. (L'agent de gestion utilise l'adresse multidiffusion 228.8.8.8.)

Avant de réessayer avec une nouvelle configuration des agents de gestion, vous devrez peut-être nettoyer le référentiel des agents de gestion. Arrêtez tous les agents dans le domaine et supprimez tous les fichiers et répertoires du répertoire du référentiel (identifié par repository.dr.path dans le fichier de configuration des agents de gestion). Cette opération doit être effectuée sur tous les hôtes avant de redémarrer les agents avec le nouveau fichier de configuration.

Les répertoires doivent être nettoyés après la suppression d'une instance HADB. (ID 6190878)

Après la suppression d'une instance HADB, les tentatives ultérieures de création de nouvelles instances à l'aide de la commande configure-ha-cluster échouent. Le problème est tel que les anciens répertoires de l'instance HADB d'origine sont conservés dans ha_install_dir/rep/* et dans ha_install_dir/config/hadb/instance_name .

Solution

Veillez à supprimer manuellement ces répertoires après la suppression d'une instance HADB.

Le démarrage, l'arrêt ou la reconfiguration de HADB peut échouer ou être interrompu. (ID 6230792, 6230415)

Sous Solaris 10 Opteron, le démarrage, l'arrêt ou la reconfiguration de HADB à l'aide de la commande hadbm risque d'échouer ou de se bloquer, en générant l'une des erreurs suivantes :


hadbm:Error 22009: The command issued had no progress in the last 
300 seconds.
HADB-E-21070: The operation did not complete within the time limit, 
but has not been cancelled and may complete at a later time.

Cette erreur peut se produire s'il existe des incohérences lors de l'écriture ou de la lecture d'un fichier nomandevice) utilisé par le processus clu_noman_srv. Vous pouvez détecter ce problème en recherchant l'un des messages suivants dans les fichiers de l'historique de HADB :


n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Child process noman3 733 
does not respond.
n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Have not heard from it in 
104.537454 sec.
n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Child process noman3 733 
did not start.

Solution

La solution suivante n'a pas été vérifiée, car le problème n'a pas été reproduit manuellement. Cependant, l'exécution de cette commande pour le nœud affecté devrait résoudre le problème.


hadbm restartnode --level=clear nodeno dbname

Notez que tous les périphériques associés au nœud seront réinitialisés. Vous devrez peut-être arrêter le nœud avant de le réinitialiser.

L'agent de gestion s'arrête avec l'exception "IPV6_MULTICAST_IF failed". (ID 6232140)

Si vous démarrez l'agent de gestion sur un hôte exécutant Solaris 8 et sur lequel plusieurs cartes réseau sont installées et que IPv6 et IPv4 sont activés simultanément, l'agent de gestion s'arrête et génère l'exception "IPV6_MULTICAST_IF failed"."

Solution

Paramétrez la variable d'environnement JAVA_OPTIONS sur -Djava.net.preferIPv4Stack=true ; par exemple : 


export JAVA_OPTIONS="-Djava.net.preferIPv4Stack=true"

Une autre solution consiste à utiliser Solaris 9 ou ultérieur, qui ne présente pas ce problème.

Le processus clu_trans_srv ne peut pas être interrompu. (ID 6249685)

Il existe un bogue dans la version 64 bits de Red Hat Enterprise Linux 3.0 selon lequel le processus clu_trans_srv passe en mode non interruptible dans le cadre d'une E/S asynchrone. Cela signifie que la commande kill -9 ne fonctionne pas et que le système d'exploitation doit être réinitialisé.

Solution

Utilisez la version 32 bits de Red Hat Enterprise Linux 3.0.

La commande hadbm ne prend pas en charge les mots de passe contenant des lettres en majuscules. (ID 6262824)

Les lettres en majuscules sont converties en minuscules lorsqu'un mot de passe est stocké dans hadb.

Solution

N'utilisez pas de mots de passe contenant des lettres en majuscules.

Une mise à niveau inférieur de HADB version 4.4.2.5 vers HADB version 4.4.1.7 entraîne l'échec de la commande ma avec différents codes d'erreur. (ID 6265419)

Lors d'une mise à niveau inférieur d'une version HADB, l'agent de gestion peut échouer avec différents codes d'erreur.

Solution

Il est possible de mettre la base de données HADB à un niveau inférieur, mais ce n'est pas le cas pour l'agent de gestion si des modifications ont été apportées à des objets du référentiel. Une fois la mise à niveau inférieur effectuée, vous devez continuer à utiliser l'agent de gestion provenant de la version HADB la plus récente.

Installation/suppression et conservation du fichier symlink. (ID 6271063)

Lors de l'installation/de la suppression du package c HADB (Solaris : SUNWhadbc, Linux : sun-hadb-c) version <m.n.u-p>, le lien symbolique symlink /opt/SUNWhadb/<m> existant n'est jamais affecté. Il est donc possible qu'un lien symbolique orphelin symlink existe.

Solution

Supprimez le lien symbolique symlink avant l'installation ou après la désinstallation, sauf s'il est en cours d'utilisation.

Il peut y avoir interaction entre les agents de gestion situés dans les zones globales et locales. (ID 6273681)

Sous Solaris 10, l'arrêt d'un agent de gestion par le biais du script ma-initd dans une zone globale provoque également l'arrêt de l'agent de gestion de la zone locale.

Solution

N'installez l'agent de gestion que dans une de ces zones.

La commande hadbm/ma doit renvoyer un message d'erreur plus clair lors de l'expiration d'une session et de sa suppression au niveau de l'agent de gestion. (ID 6275103)

Il peut arriver qu'un problème de conflit d'utilisation des ressources sur un serveur entraîne la déconnexion d'un client de gestion. Lors de la reconnexion, un message d'erreur trompeur, "hadbm:Error 22184: A password is required to connect to the management agent", peut être renvoyé.

Solution

Vérifiez s'il y a un problème de ressources sur le serveur, prenez les mesures nécessaires (par exemple, ajoutez des ressources) et relancez l'opération.

Les utilisateurs non root ne peuvent pas gérer HADB. (ID 6275319)

Une installation par le biais de Java Enterprise System (en tant que root) ne permet pas aux utilisateurs non root de gérer la base de données HADB.

Solution

Connectez-vous toujours en tant que root pour pouvoir gérer la base de données HADB.

L'agent de gestion ne doit pas utiliser d'interface spécialisée. (ID 6293912)

Les interfaces spécialisées portant des adresses IP comme 0.0.0.0 ne doivent pas être enregistrées comme des interfaces pouvant être utilisées pour des nœuds HADB dans l'agent de gestion. L'enregistrement de telles interfaces peut entraîner des problèmes si des nœuds HADB sont définis sur ces interfaces via une commande utilisateur hadbm create utilisant des noms d'hôtes à la place d'adresses IP. Les nœuds ne pourront plus communiquer, interrompant ainsi la commande create.

Solution

Lorsque vous utilisez hadbm create sur des hôtes à plusieurs interfaces, spécifiez toujours les adresses IP à l'aide d'une notation DDN.

Échecs de réassemblage sous Windows. (ID 6291562)

Sous Windows, avec certaines configurations et charges, un grand nombre d'échecs de réassemblage peut se produire dans le système d'exploitation. Le problème a été observé avec des configurations de plusieurs vingtaines de nœuds lors de l'exécution de plusieurs analyses parallèles de tables (select *). Les signes peuvent être tels que les transactions sont fréquemment abandonnées, la réparation ou la récupération peut prendre du temps et des délais d'expiration fréquents peuvent se produire dans différentes parties du système.

Solution

Pour résoudre le problème, la variable du registre Windows HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters peut être définie sur une valeur supérieure à celle par défaut de 100. Il est recommandé d'augmenter cette valeur à 0x1000 ( 4096). Pour plus d'informations, consultez l' article 811003 sur les pages de support Microsoft.

Lorsque vous exécutez hadbm start <db_name>, une partie du mot de passe entré n'est pas masquée. (ID 6303581, 6346059, 6307497)

Il est possible, lorsqu'une machine est en sous-charge, que le mécanisme de masquage échoue et que certains caractères du mot de passe entré soient affichés. Ceci pose un problème mineur de sécurité et le mot de passe doit toujours être masqué.

Solution

Entrez les mots de passe dans les fichiers correspondants (méthode généralement recommandée depuis la version Application Server 8.1) et reportez-vous y avec l'option --adminpassword ou --dbpasswordfile.

JES5 HADB installé dans une zone globale non accessible depuis des zones locales sporadiques. (ID 6460979)

Lorsque Application Server est installé dans une zone globale Solaris dans /usr/SUNWappserver , le composant HADB installé avec cette instance d'Application Server ne sera pas disponible dans des zones locales sporadiques.

Le problème est tel qu'HADB est installé dans /opt/SUNWhadb dans la zone globale, mais ce répertoire n'est pas lisible à partir de zones locales sporadiques. L'ensemble HADB dans JES5 ne peut malheureusement pas être déplacé.

Solution

Étant donné que le composant HADB d'Application Server ne peut pas être déplacé, le composant HADB doit être installé séparément dans chaque zone locale sporadique à partir de laquelle vous souhaitez accéder à HADB.