Resumen del problema: al intentar recuperar el grupo de protección de Oracle Data Guard, la configuración falla y se produce un error si HA para Oracle Database tiene dependencias en otros recursos.
Solución alternativa: establezca la propiedad external_dependencies_allowed del grupo de protección en true.
# geopg set-prop -p external_dependencies_allowed=TRUE protection_group
Resumen del problema: los proyectos o los puntos de montaje configurados con el mismo nombre en el dispositivo de destino que en el dispositivo de origen gestionado por Geographic Edition en el cluster principal tendrán como resultado un switchover o errores de recuperación.
Solución alternativa: antes de agregar el proyecto replicado de Oracle ZFS Storage Appliance al grupo de protección, asegúrese de que el dispositivo de destino no tenga un proyecto o un punto de montaje con el mismo nombre que el dispositivo de origen.
Resumen del problema: una vez que se crea un multigrupo mediante geomg create en cualquier controlador de un sitio, el multigrupo se crea automática en otros clusters del sitio si ese controlador no tiene errores de sincronización de configuración del sitio con esos clusters. Si el estado de sincronización del sitio presenta un ERROR entre dicho cluster y ese controlador, el cluster no aceptará la creación del multigrupo.
Una manera posible de intentar resolver el error de sincronización de sitio es mediante el uso del comando geosite update en ese cluster con el controlador como argumento para lograr que los datos de configuración del sitio en el cluster sean los mismos que los que existen en el controlador y, de esa manera, replicar el multigrupo en ese cluster. Esta replicación de la configuración de un multigrupo puede fallar en algunas situaciones aunque el estado de sincronización del sitio de ese cluster informe OK con respecto al controlador.
Solución alternativa: use el comando geosite leave para que ese cluster deje el sitio y, luego, vuelva a incluirlo en el sitio usando los comandos geosite add-member y geosite join.
Resumen del problema: Si la configuración de Geographic Edition en un cluster tiene grupos de protección múltiples y configuraciones de grupos múltiples, es posible que los componentes de infraestructura relacionados tarden mucho tiempo en iniciarse. Este reinicio se gestiona mediante el recurso geo-failovercontrol del tipo de recurso SUNW.scmasa, que tiene un timeout de inicio por defecto de 600 segundos. Si el recurso geo-failovercontrol tarda más tiempo en iniciarse que el timeout de inicio por defecto, la infraestructura de Geographic Edition se pone fuera de línea.
Solución alternativa: Aumente el valor de la propiedad Start_timeout del recurso geo-failovercontrol en el grupo de recursos geo-infrastructure. Si la propiedad RG_system del grupo de recursos geo-infrastructure es TRUE, cámbiela de manera temporal a FALSE antes de cambiar la propiedad del recurso.
Escriba los siguientes comandos para cambiar la propiedad Start_timeout del recurso a 1200 segundos.
$ /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
Resumen del problema: Después de un fallo de nodo en el socio secundario, el recurso de estado de replicación de Oracle GoldenGate no se inicia en otro nodo del socio secundario, debido a que no se inició el grupo de recursos de afinidad del grupo de recursos de estado de replicación de Oracle GoldenGate. Este comportamiento es válido según la afinidad del grupo de recursos. Sin embargo, el estado de replicación de datos del grupo de protección no refleja el nuevo estado del recurso de estado de replicación y el estado de replicación aún muestra OK.
Solución alternativa: Valide el grupo de protección mediante geopg validate en el cluster; esto consultará el último estado del recurso de replicación y actualizará el estado de replicación del grupo de protección.
Resumen del problema: La creación del grupo de protección falla si uno de los nodos de cluster está inactivo o Common Agent Container no se está ejecutando en un nodo y muestra el siguiente error en el terminal:
Cannot reach management agent on cluster-node : Internal Error :javax.management.RuntimeMBeanException: java.lang.IllegalArgumentException: Unmatched braces in the pattern.
Solución alternativa: Asegúrese de que Common Agent Container se esté ejecutando en todos los nodos de cluster. Si un nodo está inactivo, active el nodo o elimine el nodo y cree el grupo de protección.
Resumen del problema: La creación del grupo de protección falla si uno de los nodos del cluster está inactivo. Esta situación se produce cuando el módulo de plugin basado en secuencia de comandos intenta comprobar si todos los archivos *_script existen y son ejecutables en todos los nodos del cluster. La comprobación se realiza en todos los nodos, ya que el módulo de plugin basado en secuencia de comandos no tiene un nombre de plugin basado en secuencia de comandos para buscar el archivo de configuración. Si uno de los nodos del cluster está inactivo, se lanza una excepción y esto finaliza la creación del grupo de protección.
Solución alternativa: active o elimine el nodo, y cree un grupo de protección.
Resumen del problema: Si ejecuta el comando geopg takeover cuando ambos dispositivos ZFSSA principal y secundario están activos, el switchover en el sitio secundario falla porque existe un proyecto vacío en el dispositivo ZFSSA principal después de que se ha activado el grupo de protección.
Solución alternativa: Antes de intentar realizar el switchover en el grupo de protección, elimine el proyecto vacío del dispositivo secundario después de que se haya activado el grupo de protección.
Resumen del problema: Geographic Edition permite de forma incorrecta un switchover mientras que la replicación está en el estado Idle (export pending).
Solución alternativa: No use la función de replicación fuera de línea en proyectos gestionados por Geographic Edition.