¿Cuáles son las limitaciones para usar ZDP cuando realizo una actualización de una versión secundaria de mi clúster de base de datos de Aurora compatible con PostgreSQL?

Descripción corta

Antes de actualizar el clúster, comprueba y resuelve los siguientes factores que pueden impedir el uso de ZDP:

• Consultas de larga duración
• Operaciones de lenguaje de definición de datos (DDL) activas
• Tablas temporales
• Bloqueos de tablas activos
• Sesiones que escuchan en los canales de notificación
• Versión de TLS incompatible

Para obtener una lista completa de las limitaciones, consulta Limitaciones de aplicaciones de parches sin tiempo de inactividad.

Para obtener una lista de las versiones de Aurora compatible con PostgreSQL que admiten ZDP, consulta Actualizaciones de versiones secundarias y aplicación de parches sin tiempo de inactividad. Para identificar tu versión actual de Aurora compatible con PostgreSQL, consulta Identificación de las versiones de Amazon Aurora PostgreSQL.

Nota: El clúster debe usar la clase de instancia admitida db.r, db.t, db.x o db.serverless.

Resolución

Identificación y resolución de consultas de larga duración

Sigue estos pasos:

1. Conéctate a tu clúster de Aurora compatible con PostgreSQL.

2. Para identificar las consultas de larga duración, ejecuta el siguiente comando:

   SELECT pid, now() - pg_stat_activity.query_start AS duration, query, state
   FROM pg_stat_activity
   WHERE (now() - pg_stat_activity.query_start) > interval '5 minutes'
   AND state = 'active';

3. Para detener las consultas de larga duración, ejecuta el siguiente comando:

   SELECT pg_terminate_backend(PID);

   Nota: Sustituye PID por tu ID de proceso.

4. Para comprobar que has detenido todas las consultas de larga ejecución, vuelve a ejecutar la consulta desde el paso 2.

Comprobar y completar las operaciones de DDL

Puedes esperar a que finalicen las operaciones de DDL o puedes detenerlas. 

Sigue estos pasos:

1. Para comprobar si hay operaciones DDL activas, ejecuta el siguiente comando:

   SELECT pid, query, state, now() - query_start AS duration
   FROM pg_stat_activity
   WHERE query ILIKE '%CREATE%' OR query ILIKE '%ALTER%' OR query ILIKE '%DROP%'
   AND state = 'active';

2. Para detener una operación de DDL, ejecuta el siguiente comando:

   SELECT pg_terminate_backend(PID);

   Nota: Sustituye PID por tu ID de proceso.

3. Para confirmar que has detenido la operación de DDL, vuelve a ejecutar la consulta desde el paso 1.

Identificación y cierre de tablas temporales

Sigue estos pasos:

1. Para identificar las sesiones con tablas temporales, ejecuta el siguiente comando:

   SELECT schemaname, tablename, pidFROM pg_stat_user_tablesWHERE schemaname LIKE 'pg_temp_%';

2. Para cerrar sesiones con tablas temporales, ejecuta el siguiente comando:

   SELECT pg_terminate_backend(PID);

   Nota: Sustituye PID por tu ID de proceso.

3.  Para comprobar que has cerrado todas las tablas temporales, vuelve a ejecutar la consulta desde el paso 1.

Comprobar y liberar los bloqueos de tablas

Sigue estos pasos:

1. Para comprobar si hay bloqueos de tablas activos, ejecuta el siguiente comando:

   SELECT l.locktype, l.database, l.relation, l.page, l.tuple, l.pid, a.queryFROM pg_locks lJOIN pg_stat_activity a ON l.pid = a.pidWHERE l.granted = true AND l.locktype = 'relation';

2. Para liberar los bloqueos, ejecuta el siguiente comando para detener las sesiones en espera:

   SELECT pg_terminate_backend(PID);

   Nota: Sustituye PID por tu ID de proceso.

3. Para comprobar que has liberado todos los bloqueos, vuelve a ejecutar la consulta desde el paso 1.

Comprobar y detener los agentes de escucha de los canales de notificaciones

Sigue estos pasos:

1. Para identificar las sesiones que se escuchan en los canales de notificaciones, ejecuta el siguiente comando:

   SELECT pid, query, stateFROM pg_stat_activityWHERE query ILIKE '%LISTEN%' AND state = 'idle';

2. Para detener los agentes de escucha del canal de notificaciones, conéctate a cada sesión y ejecuta el siguiente comando:

   UNLISTEN *;

   O bien, ejecuta el comando pg_terminate_backend para detener las sesiones:

   SELECT pg_terminate_backend(PID);

Comprobación de la versión de TLS

ZDP admite conexiones TLSv1.3.

Para comprobar la versión de TLS que estás utilizando actualmente, ejecuta el siguiente comando:

SELECT pid, ssl, ssl_versionFROM pg_stat_sslJOIN pg_stat_activity USING (pid)
WHERE ssl = true;

Si usas una versión de TLS anterior a la 1.3, actualiza la versión.

Actualización del motor y supervisión de la actualización

Nota: Si se muestran errores al ejecutar comandos de la Interfaz de la línea de comandos de AWS (AWS CLI), consulta Solución de problemas de AWS CLI. Además, asegúrate de utilizar la versión más reciente de la AWS CLI.

Para actualizar el clúster de base de datos, consulta Actualización del motor de Aurora PostgreSQL a una nueva versión secundaria.

Para supervisar los eventos de actualización, ejecuta el siguiente comando describe-events de la AWS CLI:

aws rds describe-events --source-identifier CLUSTER-NAME --source-type db-cluster --start-time START-TIME

Nota: Sustituye CLUSTER-NAME por el nombre de tu clúster y START-TIME por la hora de inicio de la actualización en formato ISO.

Análisis de los resultados de ZDP

Para comprobar los resultados de ZDP en los registros de la base de datos, conéctate a tu clúster y, a continuación, ejecuta el siguiente comando:

SELECT * FROM pg_stat_activity WHERE query LIKE '%zero downtime%';

Si la operación de ZDP se realizó correctamente, verás un evento de registro similar al siguiente:

«El intento para actualizar la instancia de base de datos ###-### sin tiempo de inactividad ha finalizado. El proceso tardó 3485 ms, se conservaron 378 conexiones y se interrumpieron 0 conexiones».

Si la operación de ZDP no se realizó correctamente, verás un evento de registro similar al siguiente:

«Se completó la actualización de la versión secundaria del motor de clúster de bases de datos. Versión anterior: 13.12.9. Nueva versión: 13.18.4. Tiempo total sin conexión: 21,0 segundos. Desconectar el clúster de base de datos mientras la instancia principal completa el proceso de aplicación de parches o actualización».

Nota: ZDP opera con el máximo esfuerzo. El éxito depende de la finalización de toda la actividad de preparación y de la base de datos en el momento de la actualización.

Información relacionada

Actualización de clústeres de bases de datos de Amazon Aurora PostgreSQL

Prácticas recomendadas con Amazon Aurora PostgreSQL

Uso de Amazon Aurora PostgreSQL