Résumé du problème : la tentative de récupération de la configuration du groupe de protection Oracle Data Guard échoue avec une erreur si HA pour Oracle Database possède des dépendances sur d'autres ressources.
Solution : définissez la propriété external_dependencies_allowed des groupes de protection sur true.
# geopg set-prop -p external_dependencies_allowed=TRUE protection_group
Résumé du problème : les projets ou les points de montage configurés avec le même nom sur l'appareil cible qu'un projet ou un point de montage sur l'appareil source géré par Geographic Edition sur le cluster principal entraîneront des défaillances de commutation ou de basculement.
Solution : avant d'ajouter le projet répliqué d'Oracle ZFS Storage Appliance au groupe de protection, vérifiez que l'appareil cible ne contient pas de projet ou de point de montage portant le même nom que ceux de l'appareil source.
Résumé du problème : après la création d'un groupe multiple à l'aide de la commande geomg create sur le contrôleur d'un site, le groupe multiple est créé automatiquement sur d'autres clusters du site si ce contrôleur ne génère aucune erreur de synchronisation de la configuration du site avec ces clusters. Si le statut de synchronisation du site est ERREUR entre l'un de ces clusters et ce contrôleur, ce cluster n'accepte pas la création du groupe multiple.
Il est possible de tenter de corriger l'état d'erreur de la synchronisation du site à l'aide de la commande geosite update sur le cluster avec le contrôleur en tant qu'argument, afin de rendre les données de configuration du site sur le cluster identiques à celles existant sur le contrôleur, et ainsi de répliquer le groupe multiple sur ce cluster. Cette réplication d'une configuration de groupe multiple peut échouer dans certains cas, même si le statut de synchronisation du site de ce cluster indique OK par rapport au contrôleur.
Solution : exécutez la commande geosite leave pour que ce cluster quitte le site, puis intégrez-le à nouveau au site à l'aide des commandes geosite add-member et geosite join.
Résumé du problème : si la configuration Geographic Edition sur un cluster comporte plusieurs groupes de protection et des configurations multigroupes, les composants de l'infrastructure connexe peuvent être assez longs à démarrer. Ce démarrage est géré par la ressource geo-failovercontrol du type de ressource SUNW.scmasa, qui a un délai d'attente de démarrage par défaut de 600 secondes. Si la ressource geo-failovercontrol met plus de temps à démarrer que le délai d'attente par défaut, l'infrastructure Geographic Edition se met hors ligne.
Solution : augmentez la valeur de la propriété Start_timeout de la ressource geo-failovercontrol dans le groupe de ressources geo-infrastructure. Si la propriété RG_system du groupe de ressources geo-infrastructure a la valeur TRUE, remplacez-la temporairement par FALSE avant de modifier la propriété de ressource.
Saisissez les commandes suivantes pour faire passer la valeur Start_timeout de la ressource à 1 200 secondes.
$ /usr/cluster/bin/clresourcegroup set -p RG_system=FALSE geo-infrastructure $ /usr/cluster/bin/clresource set -p Start_timeout=1200 geo-failovercontrol $ /usr/cluster/bin/clresourcegroup set -p RG_system=TRUE geo-infrastructure
Résumé du problème : après une défaillance du noeud sur le partenaire secondaire, la ressource du statut de réplication Oracle GoldenGate ne démarre pas sur un autre noeud du partenaire secondaire car le groupe de ressources de l'affinité du groupe de ressources du statut de réplication Oracle GoldenGate n'apparaît pas. Ce comportement est correct en fonction de l'affinité du groupe de ressources. Cependant, le statut de réplication des données du groupe de protection ne reflète pas le nouveau statut de la ressource du statut de réplication et le statut affiche toujours OK.
Solution : validez le groupe de protection en exécutant la commande geopg validate sur le cluster, qui devrait interroger le dernier statut de ressource de réplication et mettre à jour le statut de réplication du groupe de protection.
Résumé du problème : la création du groupe de protection échoue si l'un des noeuds du cluster est en panne ou si le conteneur d'agents communs ne s'exécute pas sur un noeud et affiche le message d'erreur suivant sur le terminal :
Cannot reach management agent on cluster-node : Internal Error :javax.management.RuntimeMBeanException: java.lang.IllegalArgumentException: Unmatched braces in the pattern.
Solution : vérifiez que le conteneur d'agents communs est en cours d'exécution sur tous les noeuds du cluster. Si un noeud est en panne, affichez le noeud ou supprimez-le et créez le groupe de protection.
Résumé du problème : la création du groupe de protection échoue si l'un des noeuds du cluster est en panne. Cette situation survient quand le module de plug-in basé sur script tente de vérifier que tous les fichiers *_script existent et sont exécutables sur tous les noeuds de cluster. La vérification est effectuée sur tous les noeuds car le module de plug-in basé sur script n'a pas un nom de plug-in basé sur script à rechercher dans le fichier de configuration. Si l'un des noeuds est en panne, une exception est générée et la création du groupe de protection prend fin.
Solution : affichez le noeud ou supprimez-le et créez le groupe de protection.
Résumé du problème : si vous exécutez la commande geopg takeover lorsque les appareils ZFSSA principal et secondaire sont tous deux fonctionnels, la commutation vers le site secondaire échoue à cause de la présence d'un projet vide sur l'appareil ZFSSA principal d'origine après l'activation du groupe de protection.
Solution : avant de tenter une commutation du groupe de protection, supprimez le projet vide sur l'appareil secondaire après l'activation du groupe de protection.
Résumé du problème : Geographic Edition autorise par erreur une commutation alors que la réplication est à l'état Idle (export pending).
Solution : n'utilisez pas la fonction de réplication hors ligne sur des projets gérés par Geographic Edition.