Solución de errores al actualizar servidores DB2 en entornos HADR (sin reinicialización en espera)

En esta sección se describe cómo solucionar errores al actualizar de servidores DB2 en entornos HADR (sin reinicialización en espera).

Si utiliza el procedimiento Actualización de servidores Db2 en entornos HADR (sin reinicialización en espera), este procedimiento mantiene el rol de base de datos y se basa en las características normales de envío de registros y reproducción de registros comunes a la funcionalidad HADR. El procedimiento evita la necesidad de detener HADR para realizar una actualización y de tener que reiniciarlo. De esta forma, se reduce el intervalo de tiempo durante el cual no existe ninguna base de datos en espera y se elimina el coste de enviar una imagen de copia de seguridad al sitio en espera para una reinicialización.

Durante la actualización se puede producir un error en cualquier punto del procedimiento con algún componente que forme parte del sistema primario o en espera. Una actualización es un suceso planificado, por lo tanto, cualquier error se considera grave y disponer de la base de datos primaria o en espera lo antes posible resulta esencial. En la mayoría de los casos, un error hace que la base de datos primaria o en espera no estén disponibles para seguir cumpliendo su función en el procedimiento de actualización de HADR. Cuando eso sucede, es necesario detener HADR para eliminar la función de la base de datos con el error y continuar la actualización como una base de datos distinta de HADR y después reinicializar la actualización posterior a HADR.

Resulta difícil documentar todos los escenarios de error posibles, pero en este tema se explican cuáles son las acciones que se pueden realizar para solucionar los errores que se producen en determinados puntos comunes del procedimiento.

Escenario 1: En Db2 versión 10.5 Fixpack 7 o posterior, si la funcionalidad de envío de registro del primario y la funcionalidad de reproducción de registro del sistema en espera no están en buen estado, lo que hace que db2iupgrade/db2ckupgrade falle.

Si el problema no se puede solucionar en la ventana de actualización, siga el procedimiento HADR anterior que requiere la detención de HADR y la reinicialización que se describe en Actualización de servidores Db2 en entornos HADR.

Escenario 2: en Db2 versión 10.5 Fixpack 7 o posterior, si la funcionalidad de envío de registro del primario y la funcionalidad de reproducción de registro del sistema en espera están en buen estado, pero la posición de reproducción del sistema en espera sigue estando detrás de la posición de envío de registro del sistema primario, lo que hace que db2iupgrade/db2ckupgrade falle.

Asegúrese de que el retardo de la reproducción esté desactivado estableciendo el mandato hadr_replay_delay en 0. Pruebe a asignar más tiempo al sistema en espera para que se ponga al mismo nivel incrementando el valor hadr_timeout. Si ninguna de estas opciones permite que las posiciones de registro coincidan dentro de la ventana de actualización, siga el procedimiento HADR anterior que requiere la detención de HADR y la reinicialización que se describe en Actualización de servidores Db2 en entornos HADR.

Escenario 3: En Db2 versión 10.5 Fixpack 7 o posterior, si la base de datos primaria deja de estar disponible, impidiendo que se ejecute db2iupgrade/db2ckupgrade .

Si la base de datos primaria no se puede volver a activar dentro de la ventana de actualización, conmute los roles en la base de datos en espera y, a continuación, siga el procedimiento HADR anterior que requiere la detención de HADR y la reinicialización que se describe en Actualización de servidores Db2 en entornos HADR.

Escenario 4: En Db2 versión 10.5 Fixpack 7 o posterior, si la base de datos en espera deja de estar disponible, impidiendo que se ejecute db2iupgrade/db2ckupgrade .

Si la base de datos en espera no se puede volver a poner en marcha dentro de la ventana de actualización, siga el procedimiento HADR anterior que requiere la detención de HADR y la reinicialización que se describe en Actualización de servidores Db2 en entornos HADR.

Escenario 5: En Db2 versión 11.5, si la base de datos primaria deja de estar disponible, lo que impide que el procedimiento de actualización continúe en la base de datos en espera.

Si no se puede disponer otra vez de la base de datos primaria dentro del intervalo de actualización, en el sistema en espera, ejecute el mandato STOP HADR seguido de ROLLFORWARD DATABASE con la opción STOP. Esto convertirá a la base de datos en una base de datos distinta de HADR. La base de datos pasará a estar pendiente de actualización y, por lo tanto, la ejecución del mandato UPGRADE DATABASE proseguirá la actualización. Una vez completada, consulte Tareas posteriores a la actualización para servidores Db2 y Verificación de la actualización de servidores Db2. HADR debe reinicializarse.

Escenario 6: en Db2 versión 11.5, si la base de datos en espera deja de estar disponible, lo que impide que el mandato UPGRADE DATABASE se inicie en el primario.

Si no se puede disponer otra vez de la base de datos en espera dentro del intervalo de actualización, ejecute el mandato STOP HADR en la base de datos primaria. Esto convertirá a la base de datos en una base de datos distinta de HADR. La base de datos seguirá estando pendiente de actualización, por lo que debe volver a emitir el mandato UPGRADE DATABASE para continuar con la actualización. Una vez completada, consulte Tareas posteriores a la actualización para servidores Db2 y Verificación de la actualización de servidores Db2. HADR deberá reinicializarse.

Escenario 7: en Db2 versión 11.5, si la base de datos en espera deja de estar disponible mientras está en estado de actualización en curso.

Una vez ejecutado el mandato UPGRADE DATABASE en la base de datos primaria y después de que haya establecido una conexión con la base de datos en espera, la actualización continuará sin problemas en la base de datos primaria y finalizará correctamente. El problema es que no hay ninguna base de datos en espera que reproduzca datos de registro, lo cual le expone al peligro de perder la base de datos primaria. La base de datos primaria posterior a la actualización puede volver a activarse con el mandato START HADR especificando la opción BY FORCE. En este punto, debe hacer todo lo posible para resolver los problemas en la base de datos en espera. Una vez resueltos, dado que la base de datos en espera se encontraba en el estado de actualización en curso, debería ejecutar el mandato UPGRADE DATABASE. La base de datos en espera seguirá reproduciendo los datos de registro de la actualización enviados por la base de datos primaria hasta que la actualización finalice y deje de tener el estado de actualización en curso.

Escenario 8: En Db2 versión 11.5, si se ha especificado el mandato UPGRADE DATABASE con la opción REBINDALL en la base de datos primaria y la base de datos en espera deja de estar disponible mientras la actualización está en curso.

La diferencia con el Escenario 7 es que en la base de datos primaria, el mandato UPGRADE DATABASE se ha especificado con la opción REBINDALL. En este caso, el mandato UPGRADE DATABASE requiere e intenta una nueva conexión con la base de datos. Si la base de datos en espera no está disponible durante este segundo intento de conexión, el mandato UPGRADE DATABASE devuelve SQL1499W. El mensaje SQL1499W se puede devolver por muchos otros motivos por lo que será necesario contar con el registro de diagnóstico de DB2 para determinar qué es lo que ha fallado y si se aplica a este escenario. Si es así, la base de datos primaria posterior a la actualización puede volver a activarse con el mandato START HADR especificando la opción BY FORCE. La revinculación se puede seguir haciendo de forma manual en este punto. Sin embargo, debe hacerse todo lo posible por resolver los problemas con la base de datos en espera. Una vez resueltos, dado que la base de datos en espera se encontraba en el estado de actualización en curso, debería ejecutar el mandato UPGRADE DATABASE. La base de datos en espera seguirá reproduciendo los datos de registro de la actualización enviados por la base de datos primaria hasta que la actualización finalice y deje de tener el estado de actualización en curso.

En cualquier momento, si hay problemas con la actualización a Db2 versión 11.5, puede invertir la actualización o retroceder de Db2 versión 11.5 a un release anterior aDb2 versión 11.5 . Consulte Reversión de la actualización del servidor de Db2 para conocer todos los pasos necesarios para invertir una actualización de base de datos.