Ejemplos del redireccionamiento automático del cliente

El redireccionamiento de cliente automático (ACR) puede redireccionar las aplicaciones cliente de un servidor de bases de datos anómalo a un servidor de bases de datos secundario previamente identificado y configurado para este fin. Puede crear fácilmente aplicaciones cliente que prueben y demuestren esta funcionalidad de servidor de Db2® .

A continuación se muestra un ejemplo de redireccionamiento de cliente automático para una aplicación cliente (se muestra utilizando sólo pseudo-código):

        int checkpoint = 0;

        check_sqlca(unsigned char *str, struct sqlca *sqlca)
        {
           if (sqlca->sqlcode == -30081)
           {
              // as communication is lost, terminate the application right away
              exit(1);
           }
           else
           
              // print out the error
              printf(...);  

        	if (sqlca->sqlcode == -30108)
        	{
        	   // connection is re-established, re-execute the failed transaction
                 if (checkpoint == 0)
                 {
                     goto checkpt0;
                 }
        	   else if (checkpoint == 1)
                 {
                    goto checkpt1;
                 }
                 else if (checkpoint == 2)
                 {
                     goto checkpt2;
                 }
                 ....
                 exit;
        	}
         }
        }

        main()
        {
           connect to mydb;
           check_sqlca("connect failed", &sqlca);

        checkpt0:
           EXEC SQL set current schema XXX;
           check_sqlca("set current schema XXX failed", &sqlca);

           EXEC SQL create table t1...;
           check_sqlca("create table t1 failed", &sqlca);

           EXEC SQL commit;
           check_sqlca("commit failed", &sqlca);
 
           if (sqlca.sqlcode == 0)
           {
              checkpoint = 1;
           }

        checkpt1:
           EXEC SQL set current schema YYY;
           check_sqlca("set current schema YYY failed", &sqlca);

           EXEC SQL create table t2...;
           check_sqlca("create table t2 failed", &sqlca);   

           EXEC SQL commit;
           check_sqlca("commit failed", &sqlca);
 
           if (sqlca.sqlcode == 0)
           {
              checkpoint = 2;
           }
        ...
        }

En la máquina cliente, la base de datos denominada mydb está catalogada con referencia a un nodo hornet donde hornet también está catalogado en el directorio del nodo (nombre de host hornet con el número de puerto 456).

Ejemplo que implica una base de datos no HADR

En el servidor hornet (nombre de host igual a hornet con un número de puerto), se crea una base de datos mydb. Además, la base de datos mydb también se crea en el servidor alternativo (nombre de host montero con número de puerto 456). El servidor alternativo para la base de datos mydb en el servidor hornet debe actualizarse del modo siguiente:

   db2 update alternate server for database mydb using hostname montero port 456

En la aplicación de ejemplo anterior, y sin tener configurada la característica de redireccionamiento de cliente automático, si hay un error de comunicación en la sentencia create table t1, la aplicación termina. Con la característica de redireccionamiento de cliente automático configurada, el gestor de bases de datos Db2 intenta establecer de nuevo la conexión con el host hornet (con el puerto 456). Si sigue sin funcionar, el gestor de bases de datos Db2 intenta la ubicación del servidor alternativo (host montero con el puerto 456). Suponiendo que no hay ningún error de comunicación en la conexión con la ubicación del servidor alternativo, la aplicación puede continuar ejecutando sentencias posteriores (y volver a ejecutar la transacción anómala).

Ejemplo de una base de datos HADR

En el servidor hornet (el nombre de host es igual a hornet con un número de puerto), se crea la base de datos primaria mydb. También se crea una base de datos en espera en el host montero con el puerto 456. La información sobre cómo configurar HADR para una base de datos primaria y en espera se encuentra en Inicialización de la recuperación tras desastre de alta disponibilidad (HADR). El servidor alternativo para la base de datos mydb debe actualizarse del modo siguiente:

   db2 update alternate server for database mydb using hostname montero port 456

En la aplicación de ejemplo proporcionada, y sin tener configurada la característica de redireccionamiento de cliente automático, si hay un error de comunicación en la sentencia create table t1, la aplicación termina. Con la característica de redireccionamiento de cliente automático configurada, el sistema de base de datos Db2 intenta establecer de nuevo la conexión con el host hornet (con el puerto 456). Si sigue sin funcionar, el sistema de base de datos Db2 intenta la ubicación del servidor alternativo (host montero con el puerto 456). Suponiendo que no hay ningún error de comunicación en la conexión con la ubicación del servidor alternativo, la aplicación puede continuar ejecutando sentencias posteriores (y volver a ejecutar la transacción anómala).

En un entorno Db2 pureScale configurado con HADR, el comportamiento es similar. La primera vez que un cliente se conecta a la base de datos principal, el servidor devuelve las direcciones de todos los miembros de la instancia principal, además de la dirección del servidor alternativo que especifica el nombre de host y el puerto de un miembro en espera. Si un cliente no puede conectarse a un miembro en la instancia principal, lo intenta con otro. Si no puede conectarse a ningún miembro en la instancia principal, intenta la instancia en espera en la dirección del servidor alternativo especificada.

Ejemplo de SSL

También puede utilizar la redirección de cliente mientras utiliza SSL para sus conexiones. La configuración es similar a la que se muestra para el ejemplo anterior de una base de datos HADR.

En la máquina cliente, se cataloga un alias de base de datos mydb_ssl para la base de datos mydb que hace referencia a un nodo, hornet_ssl. hornet_ssl se cataloga en el directorio de nodos (el nombre de host es hornet, el número de puerto SSL es 45678 y el parámetro de seguridad se establece en SSL).

También se ha catalogado un alias de base de datos en el servidor alternativo (el nombre de host es montero, el número de puerto SSL es 45678 y el parámetro de seguridad se establece en SSL). También es necesario actualizar el servidor alternativo para el alias mydb_ssl en el servidor hornet, tal como se muestra:

db2 update alternate server for database mydb_ssl using hostname montero port 45678

En la aplicación de ejemplo proporcionada, cambie la sentencia de conexión a connect to mydb_ssl. Sin tener configurada la función de redireccionamiento automático del cliente, si hay un error de comunicación en la sentencia create table t1, la aplicación termina. Con la característica de redirección automática de cliente configurada, el gestor de bases de datos Db2 intenta establecer la conexión con el host hornet (con el puerto 45678) utilizando SSL de nuevo. Si sigue sin funcionar, el gestor de bases de datos Db2 intenta la ubicación del servidor alternativo (host montero en el puerto 45678) utilizando SSL. Suponiendo que no hay ningún error de comunicación en la conexión con la ubicación del servidor alternativo, la aplicación puede continuar ejecutando sentencias posteriores (y volver a ejecutar la transacción anómala).