Arquitectura técnica

Contexto

Las sesiones de bases de datos pueden interrumpirse durante una conmutación principal/en standby, una actualización de versión secundaria o un cambio de clase de instancia. Las aplicaciones deben verificar los estados de las sesiones y reaccionar a los cambios después de determinar:

• Si se ha interrumpido la conexión a la base de datos.
• Si la transacción ha sido interrumpida.
• Cómo realizar la compensación de transacciones.
• Cómo reconstruir el contexto de sesión de la base de datos.

Application Lossless and Transparent (ALT) garantiza la continuidad de las aplicaciones sin pérdida de datos durante una conmutación o conmutación por error primaria/en espera. Cuando ALT está habilitado:

• Se pueden evitar interrupciones de conexiones y de transacciones.
• No hay necesidad de compensación por transacción.
• No es necesario recuperar o reconstruir el contexto de sesión.

Precauciones

• Al habilitar o deshabilitar ALT, se reiniciará la instancia de RDS y la instancia de proxy.
• No se admite ALT cuando la función multiproxy está habilitada.
• rds_tac_drain_timeout controla el intervalo de tiempo de espera de drenaje de la transacción para ALT. Este parámetro tiene por defecto 5s y varía de 1s a 60s.
  • Aumente este intervalo para cargas de trabajo pesadas y transacciones que consumen mucho tiempo.
  • No se recomienda disminuir este intervalo. Si hay conexiones que no drenan transacciones dentro del intervalo de tiempo de espera de drenaje de transacciones configurado, ALT no tiene efecto para estas conexiones.

Arquitectura de ALT

Puede activarse ALT para las conexiones de la aplicación. Figura 1 muestra la arquitectura de ALT.

Figura 1 Arquitectura de ALT

Cuando ALT está habilitado para sus aplicaciones:

1. Las aplicaciones deben estar conectadas al proxy de la base de datos.
2. Durante una conmutación principal/en espera, cambio de clase de instancia o actualización de versión secundaria, RDS replica sesiones de base de datos.
3. Los registros de transacciones se drenan para establecer límites de transacción seguros.
   

   Un límite de transacción seguro es cuando se ha confirmado una transacción en la sesión actual pero la siguiente transacción aún no se ha iniciado. Se puede alcanzar un límite de transacción seguro en cualquiera de las siguientes situaciones:

   • Se ejecuta cada sentencia en un bloque de transacción con confirmación automática activada.

     start transaction;
     DML;
     commit;

   • La operación de confirmación se completa con la confirmación automática deshabilitada.
   • Se ejecuta una única sentencia DML o DDL.
   • El bloqueo se libera cuando se utiliza un bloqueo de tabla, un bloqueo de copia de respaldo o un bloqueo definido por el usuario.
   • Una transacción XA se confirma o se revierte.
4. Las sesiones de la base de datos se cambian mediante la transferencia de contextos de sesión.

   El clon de sesión puede copiar y transferir estados de sesión, incluidas las variables del sistema de sesión, las variables definidas por el usuario y otros contextos como DB_NAME y Prepared Statement.