En este apartado se describen los problemas conocidos relacionados con la base de datos de alta disponibilidad (HADB) y las soluciones asociadas.
La configuración de HADB con redes dobles en dos subredes funciona correctamente en Solaris SPARC. Sin embargo, debido a problemas en el sistema operativo o a los controladores de red en algunas plataformas de hardware, se ha observado que las plataformas Linux y Solaris x86 no siempre gestionan correctamente las redes dobles. Esto provoca los siguientes problemas con HADB:
En Linux, algunos de los procesos de HADB se bloquean al enviar mensajes. Esto hace que el nodo de HADB se reinicie y se produzcan particiones en la red.
En Solaris x86, pueden surgir algunos problemas después de un fallo de red que impidan cambiar a otras interfaces de red. Esto no sucede siempre, por lo que sigue siendo mejor tener dos redes que una sola. Estos problemas se han resuelto parcialmente en Solaris 10.
No se admite el truncamiento.
HADB no admite el uso de redes dobles en Windows 2003 (ID 5103186).
La creación de una base de datos nueva puede fallar con el siguiente error, que indica que hay muy pocos segmentos de memoria compartida disponibles:
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.
Compruebe que la memoria compartida esté configurada y que la configuración esté funcionando. En concreto, en Solaris 8, consulte el /etc/system, y compruebe que el valor de la variable shmsys:shminfo_shmseg sea, como mínimo, 6 veces el número de nodos por host.
HADB 4.3-0.16 y posterior se configura para utilizar la memoria compartida privada al crearse y adjuntarse a sus segmentos de memoria compartida (utiliza el indicador SHM_SHARE_MMU ). El uso de este indicador básicamente bloquea los segmentos de memoria compartida en la memoria física e impide que se eliminen. Esto puede fácilmente provocar problemas con instalaciones en equipos finales lentos.
Por tanto, si un programador tiene un equipo con 512 MB de memoria y mucho espacio de intercambio disponible al utilizar Application Server7.0 EE y, a continuación, instala 7.1 EE o posterior, tendrá problemas al configurar el clúster predeterminado clsetup, que crea dos nodos HADB, cada uno con un tamaño, devicesize, de 512, que da lugar a que no haya suficiente RAM física para soportar la memoria compartida que ambos nodos necesitan.
Asegúrese de que dispone de la cantidad recomendada de memoria al ubicar de forma conjunta Application Server y HADB. Consulte Requisitos de HADB y plataformas compatibles para obtener más información.
Al aumentar el tamaño de la memoria búfer o de los dispositivos usando hadbm set,, el sistema de administración comprueba la disponibilidad de los recursos cuando se crean bases de datos o se agregan nodos, pero no comprueba si hay recursos suficientes cuando se cambia el tamaño de la memoria búfer principal o del dispositivo.
Compruebe si hay espacio de disco o de memoria suficiente en todos los hosts antes de aumentar los atributos de configuración devicesize o buffersize.
No se puede registrar el mismo paquete de software con el mismo nombre en ubicaciones distintas y en hosts diferentes, por ejemplo:
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. |
HADB no admite rutas heterogéneas en los nodos de un clúster de base de datos. Asegúrese de que el directorio de instalación de HADB (--packagepath) sea el mismo para todos los hosts.
Si el agente de administración se está ejecutando en un host con varias interfaces de red, es posible que el comando create domain presente errores si no están todas las interfaces de red en la misma subred:
hadbm:Error 22020: The management agents could not establish a domain, please check that the hosts can communicate with UDP multicast. |
Los agentes de administración, a menos que estén configurados de otra forma, usarán la "primera" interfaz para difusiones UDP (se entiende como "primera" interfaz el resutado de java.net.NetworkInterface.getNetworkInterfaces()).
La mejor solución es indicarle al agente de administración qué subred debe utilizar (defina ma.server.mainternal.interfaces en el archivo de configuración, por ejemplo, ma.server.mainternal.interfaces=10.11.100.0). Otra opción es configurar el enrutador entre las subredes para que dirija los paquetes de difusión (el agente de administración utiliza la dirección de difusión 228.8.8.8).
Antes de volver a intentarlo con una configuración nueva de los agentes de administración, puede que deba limpiar el repositorio del agente de administración. Detenga todos los agentes del dominio, y elimine todos los archivos y directorios del directorio del repositorio (se identifican mediante repository.dr.path en el archivo de configuración del agente de administración). Esta acción debe realizarse en todos los hosts antes de reiniciar los agentes con un nuevo archivo de configuración.
Una vez eliminada una instancia de HADB, fallarán los intentos siguientes de crear nuevas instancias con el comando configure-ha-cluster. El problema es que los antiguos directorios permanecen en la instancia de HADB original en ha_install_dir/rep/* y ha_install_dir/config/hadb/instance_name .
Asegúrese de que elimina manualmente estos directorios tras eliminar una instancia de HADB.
En Solaris 10 Opteron, el inicio, la detención o la reconfiguración de HADB usando el comando hadbm pueden fallar o generar bloqueos con alguno de los siguientes errores:
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. |
Esto puede suceder si hay incoherencias al leer o escribir en un archivo (nomandevice) que esté utilizando el proceso clu_noman_srv. Este problema se puede detectar buscando los siguientes mensajes en los archivos del historial 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. |
La siguiente solución no se ha probado, puesto que no se ha reproducido el problema manualmente. Sin embargo, la ejecución de este comando para el nodo afectado debería resolver el problema.
hadbm restartnode --level=clear nodeno dbname |
Tenga en cuenta que se reiniciarán todos los dispositivos del nodo. También es posible que haya que detener el nodo antes de reiniciarlo.
Cuando se inicia en un host que ejecuta Solaris 8 con varias tarjetas NIC instaladas, si hay una mezcla de tarjetas con IPv6 e IPv4 habilitados, el agente de administración puede terminar con la excepción "IPV6_MULTICAST_IF failed."."
Defina la variable de entorno JAVA_OPTIONS en -Djava.net.preferIPv4Stack=true como, por ejemplo:
export JAVA_OPTIONS="-Djava.net.preferIPv4Stack=true" |
De lo contrario, use Solaris 9 o una versión posterior que no esté afectada por este problema.
Hay un error en la versión de 64 bits de Red Hat Enterprise Linux 3.0 que hace que el proceso clu_trans_srv termine en modo sin interrupción cuando se realiza una E/S asíncrona. Esto significa que kill -9 no funciona y el sistema operativo debe reiniciarse.
Use una versión de 32 bits de Red Hat Enterprise Linux 3.0.
Las letras mayúsculas en las contraseñas se convierten en minúsculas cuando la contraseña se almacena en hadb.
No use contraseñas que contengan letras mayúsculas.
Al retroceder en las versiones, el agente de administración puede fallar con distintos códigos de error.
Es posible retroceder en la versión de la base de datos de HADB, sin embargo, el agente de administración no podrá retroceder en su versión si se han hecho cambios en los objetos del repositorio. Después de retroceder en la versión, deberá usar el agente de administración de la última versión de HADB.
Con respecto a la instalación o eliminación del paquete de HADB (Solaris: SUNWhadbc, Linux: sun-hadb-c) versión <m.n.u-p>, symlink /opt/SUNWhadb/<m> no se modifica una vez creado. En consecuencia, es posible que exista un symlink huérfano.
Elimine el symlink antes de la instalación o después de la desinstalación, a menos que esté en uso.
En Solaris 10, al detener el agente de administración usando la secuencia de comandos ma-initd en una zona global, se detiene también el agente de administración en la zona local.
No instale el agente de administración en la zona global y la local.
A veces un problema de contención de recursos en el servidor puede provocar la desconexión de un cliente de administración. Al volver a conectar, puede devolverse el siguiente mensaje de error confuso "hadbm:Error 22184: A password is required to connect to the management agent".
Compruebe si hay algún problema con los recursos en el servidor, realice las acciones necesarias (por ejemplo, agregue más recursos) y vuelva a intentar la operación.
La instalación de Java Enterprise System (como root) no permite que los usuarios que no sean root administren HADB.
Inicie sesión siempre como root para poder administrar HADB.
Las interfaces de uso especial con direcciones IP similares a 0.0.0.0 no deberían registrarse como interfaces válidas para los nodos de HADB en el agente de administración. El registro de dichas interfaces podría provocar problemas si los nodos de HADB se configuran en estas interfaces mediante la ejecución del comando hadbm create por parte del usuario con nombres de host en lugar de con direcciones IP. Los nodos no podrán establecer comunicación, lo que provocara el bloqueo del comando create.
Al utilizar hadbm create en hosts con varias interfaces, especifique siempre explícitamente las direcciones IP con una notación DDN.
En la plataforma Windows, con determinadas configuraciones y cargas, es posible que se produzca un gran número de errores de reensamblaje en el sistema operativo. Se ha detectado este problema con configuraciones de más de veinte nodos al ejecutar varios análisis de tabla (select *) en paralelo. Entre los síntomas detectados, se incluyen los siguientes: las transacciones se anulan frecuentemente, el proceso de reparación o recuperación tarda mucho tiempo en completarse, y se agota frecuentemente el tiempo de espera en diversas partes del sistema.
Para solucionar el problema, puede establecer la variable del registro de Windows HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters en un valor superior a 100 (valor predeterminado). Se recomienda que aumente este valor a 0x1000 ( 4096). Para obtener más información, consulte el artículo 811003 en las páginas de asistencia técnica de Microsoft.
Es posible que, cuando un equipo esté realizando una carga, el mecanismo de ocultación falle y se expongan algunos caracteres de la contraseña introducida. Esto representa un riesgo de seguridad menor y la contraseña debería estar siempre oculta.
Guarde las contraseñas en sus propios archivos de contraseñas (el método recomendado normalmente desde Application Server 8.1) y consúltelas con las opciones --adminpassword o --dbpasswordfile.
Cuando se instala Application Server en una zona global de Solaris en el directorio /usr/SUNWappserver , el componente HADB instalado con la instancia de Application Server no estará disponible en las zonas locales dispersas.
El problema es que HADB se instala en el directorio /opt/SUNWhadb de la zona global, pero este directorio no tiene acceso de lectura desde las zonas locales dispersas. Desafortunadamente, el HADB integrado en JES5 no se puede reubicar.
Como el componente HADB de Application Server no se puede reubicar, debe instalarse por separado en cada zona local dispersa desde la que desee acceder a HADB.