Notas de la versión de Sun Java System Application Server Enterprise Edition 8.1 2005Q2

- Previous: Compatibilidad de HADB con los sistemas de archivos
- Next: Limitaciones conocidas de SQL

## Actualización de la base de datos de alta disponibilidad

- Migración de tareas y datos previos a la actualización

- Procedimiento de actualización

- Comprobación de la actualización

- Información especial sobre la implementación y la actualización

### Migración de tareas y datos previos a la actualización

##### Antes de empezar

Los usuarios deben conservar los archivos del historial de HADB, los archivos de configuración del agente de administración, los archivos de registro y el repositorio y todos los dispositivos de datos externos a la ruta de instalación. De lo contrario, esto se debe hacer antes de la actualización. Para mover el repositorio de administración y los archivos de configuración:

1. Detenga todos los agentes de administración antiguos y deje los nodos de HADB ejecutándose.

2. En cada host, mueva el directorio del repositorio a la nueva ubicación.

3. En cada host, copie el directorio `dbconfig` en la nueva ubicación.

4. En cada host, actualice el archivo `mgt.cfg` y defina la ruta correcta para `dbconfig` y el directorio del repositorio.

5. Inicie los agentes de administración usando el archivo actualizado `mgt.cfg`.

### Procedimiento de actualización

Para actualizar de la versión 4.4.x de HADB a la versión 4.4.2-7, lleve a cabo el siguiente procedimiento:

1. Realice las tareas previas a la actualización mencionadas anteriormente si es necesario.

2. Instale la versión 4.4.2-7 de HADB en todos los hosts de HADB (en una ruta distinta de la de la versión 4.4.x, por ejemplo, en `/opt/SUNWhadb/4.4.2-7`).

3. Instale la versión 4.4.2-7 de HADB en los hosts del cliente `hadbm`, en caso de que sean diferentes de los de los hosts de HADB.

4. Detenga todos los agentes de administración que se estén ejecutando en todos los hosts de HADB.

5. Inicie los procesos del agente de administración usando el software de la nueva versión, pero con los archivos de configuración antiguos. En los pasos que quedan, utilice el comando `hadbm` que se incluye en el directorio `bin` de la nueva versión.

6. Registre el paquete en el dominio de administración (el nombre del paquete predeterminado pasa a ser V4.4, por lo que será necesario utilizar otro nombre de paquete para evitar conflictos con los paquetes existentes que tengan el mismo nombre):

       hadbm registerpackage --packagepath=/opt/SUNWhadb/4.4.2-7 V4.4.2-7

7. Ejecute el comando `hadbm listpackages` y compruebe que el nuevo paquete esté registrado en el dominio.

8. Reinicie la base de datos con la nueva versión 4.4.2-7 de `hadbm`. Si es necesario mover los dispositivos y los archivos del historial, ejecute la actualización en línea junto con la definición de nuevas rutas para dispositivos y archivos del historial en una única operación:

       hadbm set packagename=V4.4.2-7,devicepath=new_devpath,
       historypath=new_histpath

   De lo contrario, si los dispositivos y los archivos del historial están ya fuera del directorio de instalación, ejecute el siguiente comando, que sólo realiza un reinicio por turnos de los nodos:

       hadbm set packagename=V4.4.2-7 database name

9. Compruebe que la base de datos esté ejecutándose (para ello, use el comando `hadbm status`) y que funcione normalmente, atendiendo las transacciones de los clientes.

10. Si todo está funcionando, la instalación antigua podrá eliminarse posteriormente. Antes de anular el registro del paquete antiguo, elimine del depósito `ma` todas las referencias al mismo. De lo contrario, `hadbm unregisterpackage` fallará y mostrará un error que indica que el paquete está en uso ("package in use").Una operación de reconfiguración ficticia, por ejemplo, `hadbm set connectiontrace=same as previous value`, eliminará todas las referencias al paquete antiguo. Ahora, proceda a anular el registro del paquete antiguo:

        hadbm unregisterpackage [--hosts=host-list] old pacakge name

11. Elimine la instalación antigua del sistema de archivos.

### Comprobación de la actualización

En Solaris, para probar que la actualización es correcta, compruebe si la actualización se ha realizado correctamente:

1. Asegúrese de que los procesos que se estén ejecutando usen los nuevos binarios. Compruebe lo siguiente en todos los nodos de HADB:

       new path/bin/ma -v
       new path/bin/hadbm -v

2. Compruebe si se está ejecutando la base de datos. El siguiente comando debería mostrar que todos los nodos de HADB se están “ejecutando”.

       new path/bin/hadbm status -n

3. Asegúrese de que los productos que usen HADB hayan cambiado sus punteros para que señalen a la nueva ruta de HADB.

4. Los productos que usan HADB pueden ejecutar sus pruebas de actualización para verificar que la actualización de HADB también está funcionando.

   Después de realizar una actualización en línea, si la nueva versión no funciona correctamente, vuelva a usar la versión anterior de HADB. Sin embargo, si ha habido un cambio en el repositorio del agente de administración, será posible volver a una versión anterior de HADB, pero el nuevo agente de administración deberá estar ejecutándose.

### Información especial sobre la implementación y la actualización

En este apartado se incluye información adicional acerca de la actualización y la implementación de HADB.

- Implementación

- Actualización en línea de 4.4.1 a 4.4.2

#### Implementación

- El dispositivo de almacenamiento, y los archivos de registro y de historial de los discos sólo locales no utilizan sistemas de archivos montados de forma remota.

- Si hay más de un nodo en un host, se recomienda que los dispositivos de cada nodo estén en discos diferentes. De lo contrario, la contención del disco podría reducir el rendimiento. Los indicios de este problema se pueden ver en los archivos del historial mediante mensajes como, por ejemplo, `BEWARE - last flush/fputs took too long (ATENCIÓN: los últimos vaciados/entradas tardaron demasiado tiempo)`. Cuando un único nodo tiene más de un archivo de dispositivos de datos, se recomienda usar distintos discos para dichos archivos de dispositivos.

- Use los discos locales (preferiblemente discos separados de los que se usan para los dispositivos de datos) para instalar binarios de HADB en los hosts de HADB. La contención del disco o los retrasos de NFS podrían provocar que se reinicie el nodo, con el mensaje de advertencia, `Process blocked for` `nnn``, max block time is` `nnn` (Proceso bloqueado durante nnn; tiempo máximo de bloqueo, nnn) en los archivos del historial.

- No coloque los dispositivos de HADB, los archivos de historial, los directorios del agente de administración y los archivos de configuración del agente en la ruta del paquete HADB. Esto causará problemas en el momento de actualizar a nuevas versiones y de eliminar la ruta del paquete antiguo.

- Esta versión de HADB se admite para un máximo de 28 nodos; 24 de ellos activos y 4 de reserva.

- Se recomienda utilizar la misma versión para el controlador JDBC y para el servidor HADB.

- No se admite el uso de IPv6, sólo de IPv4.

- La longitud de la línea de comandos en Windows está restringida a 2048 bytes.

- La red debe configurarse para la multidifusión UDP.

- Debido al excesivo intercambio observado en las actualizaciones 1 a 3 de RedHat Enterprise Linux 3.0, no se recomienda su uso como plataforma de implementación. Este problema se ha solucionado en RedHat Enterprise Linux 3.0 Update 4.

- Posibilidad de ejecutar `NSUP` con prioridad de tiempo real.

  Los procesos (`clu_nsup_srv` ) del supervisor de nodos (`NSUP`) garantizan la alta disponibilidad de HADB con ayuda del intercambio de mensajes de latidos (heartbeat) de una forma periódica. La temporización se ve afectada cuando se utiliza `NSUP` con otros procesos provocando la aniquilación del recurso. La consecuencia es una falsa partición de la red y que el nodo se reinicia precedido de una advertencia “Process blocked for `n` seconds” (Proceso bloqueado durante x segundos) en los archivos del historial, lo que da como resultado transacciones canceladas y otras excepciones.

  Para solucionar este problema, `clu_nsup_srv` (que se encuentra en `installpath``/lib/server`) debe tener el conjunto de bits `suid` y el archivo debe ser propiedad del usuario root. Esto se consigue de forma manual mediante los comandos:

      # chown root clu_nsup_srv
      # chmod u+s clu_nsup_srv

  Esto hace que el proceso `clu_nsup_srv` se ejecute como el usuario `root` cuando se inicia y esto, a su vez, permite que el proceso se asigne a sí mismo automáticamente prioridad de tiempo real después del inicio. Para evitar cualquier repercusión negativa en la seguridad usando `setuid`, la prioridad en tiempo real se define al principio y el proceso retrocede al UID efectivo una vez que se haya cambiado la prioridad. Otros procesos de HADB disminuirán su prioridad a un tipo de prioridad de tiempo compartido.

  Si NSUP no pudo definir la prioridad de tiempo real, se emite una advertencia: “Could not set realtime priority” (No se pudo establecer una prioridad de tiempo real) (`unix: errno will be set to EPERM`), que se escribe en el archivo `ma.log` y se continúa sin prioridad de tiempo real.

  Hay casos en los que no es posible establecer prioridades de tiempo real, por ejemplo:

  - Cuando la instalación se ha efectuado en zonas no globales de Solaris 10

  - Cuando los privilegios `PRIV_PROC_LOCK_MEMORY` (Permitir que un proceso bloquee páginas en la memoria física) y/o los privilegios `PRIV_PROC_PRIOCNTL` se han revocado en Solaris 10

  - Los usuarios desactivan los permisos `setuid`

  - Los usuarios instalan el software como archivos tar (opción de instalación nonroot para `App.server`)

  El proceso `clu_nsup_srv` no requiere recursos de la CPU, su huella es pequeña y si se ejecuta con prioridad de tiempo real no repercutirá en el rendimiento.

- Configuración de rutas múltiples de red IP para HADB para Solaris (se ha probado sólo en Solaris 9).

  Sun recomienda que los hosts de Solaris que ejecutan HADB se configuren con rutas múltiples de red para garantizar la mayor disponibilidad posible de la red. La configuración de las rutas múltiples de red se describe detalladamente en IP Network Multipathing Administration Guide. Si opta por usar rutas múltiples con HADB, consulte el apartado sobre administración de rutas múltiples de IP Network Multipathing Administration Guide para configurar las rutas múltiples antes de continuar con la adaptación de la configuración de rutas múltiples para HADB, tal y como se describe más abajo. IP Network Multipathing Administration Guide forma parte de la colección de documentación relacionada con el administrador de sistemas de Solaris 9 y se puede descargar desde `http://docs.sun.com`.

  - Establecimiento del tiempo de detección de fallos de la interfaz de red

    Para que HADB sea compatible con la conmutación por error de rutas múltiples, el tiempo de detección de fallos de la interfaz de red no debe superar los 1000 milisegundos, tal y como especifica el parámetro `FAILURE_DETECTION_TIME` en `/etc/default/mpathd`. Edite el archivo y cambie el valor de este parámetro a `1000` si el valor original es superior:

        FAILURE_DETECTION_TIME=1000

    Para que el cambio surta efecto, ejecute el siguiente comando:

        pkill -HUP in.mpathd

  - Direcciones IP que se deben usar con HADB

    Tal y como se describe en Solaris IP Network Multipathing Administration Guide, las rutas múltiples suponen la agrupación de interfaces de red físicas en grupos de interfaces con rutas múltiples. Cada interfaz física en un grupo de este tipo cuenta con dos direcciones IP asociadas: una dirección de interfaz física y una dirección de prueba. Para transmitir datos, sólo se puede usar la dirección de interfaz física, mientras que la dirección de prueba es sólo para uso interno de Solaris. Cuando se ejecuta `hadbm create --hosts`, cada host debe especificarse sólo con una dirección de interfaz física desde el grupo de rutas múltiples.

  - Ejemplo

    Supongamos que el host 1 y el 2 tienen dos interfaces de red físicas cada uno de ellos. En cada host, estas dos interfaces están configuradas como grupos de rutas múltiples y están ejecutando `ifconfig -a`, por lo que se obtiene lo siguiente:

    Host 1

        bge0: flags=1000843<mtu 1500 index 5 inet 129.159.115.10 netmask ffffff00
        broadcast 129.159.115.255 groupname mp0
        bge0:1: flags=9040843<mtu 1500 index 5 inet 129.159.115.11 netmask ffffff00
        broadcast 129.159.115.255
        bge1: flags=1000843<mtu 1500 index 6 inet 129.159.115.12 netmask ffffff00
        broadcast 129.159.115.255 groupname mp0
        bge1:1: flags=9040843<mtu 1500 index 6 inet 129.159.115.13 netmask ff000000
        broadcast 129.159.115.255

    Host 2

        bge0: flags=1000843<mtu 1500 index 3 inet 129.159.115.20 netmask ffffff00
        broadcast 129.159.115.255 groupname mp0
        bge0:1: flags=9040843<mtu 1500 index 3 inet 129.159.115.21 netmask ff000000
        broadcast 129.159.115.255
        bge1: flags=1000843<mtu 1500 index 4 inet 129.159.115.22 netmask ffffff00
        broadcast 129.159.115.255 groupname mp0
        bge1:1: flags=9040843<mtu 1500 index 4 inet 129.159.115.23 netmask ff000000
        broadcast 129.159.115.255

    Aquí, las interfaces de red de los dos hosts son las que aparecen como `bge0` y `bge1`. Las que aparecen como `bge0:1` y `bge1:1` son las interfaces de prueba de rutas múltiples (por lo tanto, están marcadas como DEPRECATED [en desuso] en el resultado de `ifconfig`), tal y como se describe en IP Network Multipathing Administration Guide.

    Para configurar HADB en este entorno, seleccione una dirección de interfaz física de cada host. En este ejemplo, elegimos `129.159.115.10` del host 1 y `129.159.115.20` del host 2. Para crear una base de datos con un nodo de base de datos por host, use el siguiente argumento para `hadbm create`:

        --host 129.159.115.10,129.159.115.20

    Para crear una base de datos con dos nodos de base de datos en cada host, use el siguiente argumento:

        --host 129.159.115.10,129.159.115.20,129.159.115.10,129.159.115.20

    En ambos casos, la variable `ma.server.mainternal.interfaces` de los dos hosts debe establecerse en `129.159.115.0/24`.

#### Actualización en línea de 4.4.1 a 4.4.2

No es posible actualizar en línea de 4.2 ó 4.3 a 4.4. Sin embargo, la versión 4.4 admite actualizaciones en línea para las versiones futuras. Para actualizar de 4.4.1 a 4.4.2, lleve a cabo los siguientes pasos:

1. Instale 4.4.2 en todos los hosts de HADB (en una ruta distinta de 4.4.1, por ejemplo en `/opt/SUNWhadb/4.4.2-6`).

2. Instale la nueva versión en los hosts `hadbm client`.

3. Detenga todos los agentes de administración que se estén ejecutando en los hosts de HADB.

4. Inicie los procesos del agente de administración usando el software de la nueva versión, pero con los archivos de configuración antiguos. En los pasos que quedan, utilice el comando `hadbm`, que se incluye en el directorio `bin` de la nueva versión.

5. Registre el paquete en el dominio de administración (el nombre predeterminado del paquete pasa a ser `V4.4`, por lo que será necesario utilizar otro nombre de paquete para evitar conflictos con los paquetes existentes que tengan el mismo nombre):

       hadbm registerpackage --packagepath=/opt/SUNWhadb/4.4.2-6 V4.4.2

6. Reinicie la base de datos con la nueva versión (el siguiente comando realiza un reinicio por turnos de los nodos):

       hadbm set packagename=V4.4.2 database_name

7. Compruebe que la base de datos esté “ejecutándose” (para ello, use el comando `hadbm status`) y que funcione normalmente atendiendo las transacciones de los clientes.

8. Si todo está funcionando, la instalación antigua podrá eliminarse posteriormente.

   Antes de anular el registro del paquete antiguo, elimine todas las referencias a él del repositorio `ma`. De lo contrario, `hadbm unregisterpackage` fallará y mostrará un error que indica que el paquete está en uso (package in use).Una operación de reconfiguración ficticia, por ejemplo, hadbm set connectiontrace=`<same_as_previous_value>`, eliminará todas las referencias al paquete antiguo. Ahora, proceda a anular el registro del paquete antiguo:

       hadbm unregisterpackage [--hosts=<host_list>] <old_package_name>

   Elimine la instalación antigua del sistema de archivos, tal y como se describe en las installation instructions de HADB.

- Previous: Compatibilidad de HADB con los sistemas de archivos
- Next: Limitaciones conocidas de SQL

- © 2010, Oracle Corporation and/or its affiliates