Prácticas recomendadas para actualizar versiones mayores y menores de Amazon RDS PostgreSQL

Por Vivek Singh, Especialista de Bases de Datos Senior en AWS

Ocasionalmente, PostgreSQL publica nuevas versiones menores y mayores que incluyen correcciones para errores frecuentes, problemas de seguridad y problemas de corrupción de datos. Por lo general, el objetivo de Amazon RDS es admitir las nuevas versiones del motor en un plazo de cinco meses a partir de su disponibilidad. También debe actualizar sus instancias de RDS PostgreSQL de RDS cuando una versión determinada esté fuera de soporte. En este caso, RDS envía correos electrónicos sugiriendo que actualice las instancias de la base de datos. Puede actualizar sus instancias mediante la consola de RDS o el comando modify-db-instance de AWS CLI. También puede actualizar las instancias a las versiones menores adecuadas habilitando las actualizaciones automáticas de versiones menores.

Si bien RDS administra las actualizaciones, debe conocer los problemas comunes, los pasos necesarios, y las prácticas recomendadas para realizar la actualización con el menor impacto en su empresa. Esta publicación trata sobre la actualización del motor de base de datos PostgreSQL de RDS, e incluye los siguientes aspectos:

• Que sucede durante las actualizaciones de versiones mayores y menores
• Problemas comunes que ocurren durante las actualizaciones
• Entendiendo la característica de RDS “Actualización Automatizada de Versiones Menores”
• Preparando una actualización

Actualizaciones de versiones mayores y menores

A partir de PostgreSQL 10, un aumento en el primer dígito de su número de versión indica una nueva versión mayor, por ejemplo, de la versión 10 a la 11. El segundo dígito indica una versión menor, por ejemplo, de la versión 10.4 a la 10.9. Antes de PostgreSQL 10, el segundo dígito también podía indicar una versión mayor, como de la versión 9.5 a la 9.6, mientras que un tercer dígito indicaba una versión menor, por ejemplo, de la versión 9.6.5 a la 9.6.10.

Las versiones menores corrigen vulnerabilidades de seguridad, errores de funcionalidad y, por lo general, no añaden nuevas funciones. Las versiones menores nunca cambian el formato de almacenamiento interno y siempre son compatibles con las versiones menores anteriores y posteriores del mismo número de versión mayor. Por ejemplo, la versión 10.4 es compatible con la versión 10.1 y la versión 10.6. Del mismo modo, la versión 9.5.3 es compatible con las versiones 9.5.0, 9.5.1 y 9.5.6. Para actualizar entre versiones compatibles, RDS reemplaza los archivos binarios mientras el servidor está inactivo y lo reinicia. El directorio de datos permanece inalterado. Esta es la razón por la que las actualizaciones menores son más rápidas en comparación con las actualizaciones mayores.

Para las versiones mayores de PostgreSQL, el formato interno de las tablas del sistema, los archivos de datos, y el formato de almacenamiento interno de datos también cambian. Esto complica las actualizaciones. RDS usa la herramienta pg_upgrade de PostgreSQL para realizar actualizaciones mayores.

En actualizaciones de versiones mayores, RDS ejecuta los siguientes pasos:

1. Toma un snapshot antes de la actualización. Este snapshot se puede utilizar para abortar (rollback) el proceso y regresar a la versión anterior después, si es necesario.
2. Detiene la instancia PostgreSQL y la prepara para una actualización.
3. Utiliza la herramienta pg_upgrade para ejecutar la tarea de actualización en la instancia.
4. Toma otro snapshot después de la actualización y ajusta la configuración de redes.

Cuando RDS inicia el paso 1, la instancia cambia su status de Available (Disponible) a Upgrading (Actualizando). Después del paso 4, el estatus de la instancia regresa a Available (Disponible).

La siguiente tabla resume las diferencias más significativas entre los pasos involucrados en actualizaciones de versiones mayores y menores:

Problemas comunes que ocurren durante una actualización

En ciertas ocasiones, la actualización de RDS PostgreSQL presenta ciertos problemas. Estos problemas están relacionados con tipos de datos y objetos de bases de datos no compatibles. La bitácora de eventos de la base de datos pg_upgrade.log contiene detalles de estos problemas. Algunos de los problemas se mencionan a continuación:

INCOMPATIBLE_PARAMETER

Este error se produce si un parámetro relacionado con la memoria, como shared_buffer o work_memory, se configuró demasiado grande y provocó un error en el script pg_upgrade. Para solucionar el problema, debe reducir los valores e intentar la actualización de nuevo.

STORAGE_FULL

Mientras se ejecuta el script pg_upgrade, la instancia puede quedarse sin espacio en disco. Esto hace que el script falle. Aparece un mensaje de error similar al siguiente:

pg_restore: [archiver (db)] Error while PROCESSING TOC: 
pg_restore: [archiver (db)] could not execute query: ERROR: could not create file "base/12345/12345678": No space left on device 

Para resolver este problema, al realizar la actualización, asegúrese de que la instancia tenga suficiente espacio de almacenamiento libre en función de la cantidad de bases de datos y archivos de datos.

Logical replication slots

Si la base de datos está utilizando “logical replication slots”, la actualización de versión principal falla y muestra el siguiente mensaje:

PreUpgrade checks failed: The instance could not be upgraded because one or more databases have logical replication slots. Please drop all logical replication slots and try again.

Para resolver el problema, detenga cualquier tarea de DMS o replicación lógica en ejecución y elimine todas las ranuras de replicación (logical replication slots) existentes. Ejecute la siguiente sentencias SQL:

SELECT * FROM pg_replication_slots;
SELECT pg_drop_replication_slot(slot_name);

Release date dependency

Si la fecha de lanzamiento de la versión de destino es anterior a la fecha de lanzamiento de la versión actual, no podrá actualizar la instancia. Aparece un mensaje de error similar al siguiente:

Cannot upgrade postgres from 9.5.12 to 9.6.6 (Service: AmazonRDS; Status Code: 400; Error Code: InvalidParameterCombination; Request ID: 12345ab-12345ab-12345-ab)

En el ejemplo anterior, la fecha de lanzamiento de la versión 9.5.12 es el 1 de marzo de 2018, mientras que la fecha de lanzamiento de la versión 9.6.6 es el 9 de noviembre de 2017. Para solucionar este problema, consulte las notas de lanzamiento oficiales de PostgreSQL para conocer la fecha de lanzamiento y busque la versión secundaria más reciente que esté disponible

Master user name

Si el nombre de usuario maestro (master) comienza por pg_, se produce un error en la actualización y aparece el siguiente mensaje de error:

PreUpgrade checks failed: The instance could not be upgraded because one or more role names start with 'pg_'. Please rename all roles with names that start with 'pg_' and try again

Para resolver este problema, cree otro usuario con membresía en el rol rds_superuser. También debe ponerse en contacto con soporte técnico de AWS para actualizar este usuario como el nuevo usuario maestro.

Entendiendo la característica “Actualización Automatizada de Versiones Menores”

Puede configurar su instancia de PostgreSQL de RDS con la opción “Actualización Automatizada de Versiones Menores” que permite realizar una actualización menor automáticamente cada vez que RDS ponga una versión a disposición para actualizaciones. Por ejemplo, si su instancia de PostgreSQL de RDS es actualmente la versión 10.5 y habilita las actualizaciones automáticas de versiones secundarias, se actualizará automáticamente a la versión 10.6 durante el siguiente período de mantenimiento. No se actualizará la instancia RDS automáticamente a ninguna versión secundaria posterior, a menos que RDS la ponga a disposición para ello.

No todas las versiones menores están disponibles para actualizaciones automáticas. Para encontrar las versiones disponibles para actualizaciones automáticas, introduzca el siguiente comando de AWS CLI:

[ec2-user@ip- ~]$ aws rds describe-db-engine-versions --engine postgres | grep -A 1 AutoUpgrade| grep -A 2 true |grep PostgreSQL | sort --unique | sed -e 's/"Description": "//g' | sed -e 's/",//g'
PostgreSQL 10.6-R1
PostgreSQL 9.4.20-R1
PostgreSQL 9.5.15-R1
PostgreSQL 9.6.11-R1

Preparando una actualización de versión menor

Para una actualización de versión menor complete primero los siguientes pasos:

1. Revise las notas oficiales de la versión PostgreSQL que planea instalar para entender los cambios introducidos en la nueva versión.
2. Busque la siguiente versión secundaria adecuada según la ruta de actualización. Puede utilizar un comando de AWS CLI para buscar las versiones secundarias de PostgreSQL de RDS superiores disponibles. Por ejemplo, para buscar versiones secundarias superiores de una instancia que se encuentra actualmente en la versión 9.5.12, introduzca el siguiente comando de AWS CLI:

[ec2-user@ip-~]$ aws rds describe-db-engine-versions --engine postgres --engine-version 9.5.12 | grep -A 500 "ValidUpgradeTarget"| grep "EngineVersion"| grep 9.5| sed -e 's/"//g' |sed -e 's/EngineVersion: /PostgreSQL /g'
PostgreSQL 9.5.13
PostgreSQL 9.5.14
PostgreSQL 9.5.15
PostgreSQL 9.5.16
PostgreSQL 9.5.18
PostgreSQL 9.5.19 

3. Pruebe las aplicaciones con la carga de trabajo típica en la nueva versión secundaria para calcular interrupciones y el rendimiento esperados. Para probar la actualización, tome un snapshot de la instancia de producción, restáurela en un entorno de prueba y actualícela a la nueva versión secundaria. Para limitar las posibilidades de que se produzca una interrupción durante la actualización, cierre todas las conexiones existentes y tome un snapshot manual antes de ejecutar la actualización, de modo que el snapshot previo a la actualización sea más rápido. También puede utilizar réplicas de lectura para minimizar la interrupción durante una actualización menor de la versión. Para ello debe crear una réplica de lectura y aplicar la actualización menor en la réplica. Una vez que la réplica esté sincronizada con la instancia de origen, promuévala como instancia primaria y dirija la aplicación a la nueva instancia.

Preparando una actualización de versión mayor

Para una actualización de versión mayor complete primero los siguientes pasos:

1. Revise las notas oficiales de la versión PostgreSQL que planea instalar para entender los cambios introducidos en la nueva versión.
2. Busque la siguiente versión mayor adecuada según la ruta de actualización. Por ejemplo, para buscar versiones mayores superiores de una instancia que se encuentra actualmente en la versión 9.6.12, introduzca el siguiente comando de AWS CLI:

[ec2-user@ip-~]$ aws rds describe-db-engine-versions --engine postgres --engine-version 9.6.12 | grep -A 200 "ValidUpgradeTarget"|grep "EngineVersion"| sed -e 's/"//g' |sed -e 's/EngineVersion: /PostgreSQL /g'
PostgreSQL 9.6.14
PostgreSQL 9.6.15
PostgreSQL 10.7
PostgreSQL 10.9
PostgreSQL 10.10
PostgreSQL 11.2

RDS PostgreSQL ahora soporta la actualización de varias versiones mayores en un solo paso.

3. Elimine cualquier VIEW en función de los catálogos del sistema de la versión de destino. Por ejemplo, una VIEW que depende de pg_stat_activity, no puede actualizarse de 9.5 a 9.6 porque la columna de espera se reemplazó por wait_event_type y wait_event.

4. Elimine cualquier tipo de datos unknown dependiendo de la versión de destino elegida. Por ejemplo, la versión 10 dejó de soportar el tipo de datos unknown. Un tipo de datos unknown en la versión 9.6 no puede actualizarse de la versión 9.6 a la 10.6 y muestra el siguiente mensaje de error:

Database instance is in a state that cannot be upgraded: PreUpgrade checks failed: The instance could not be upgraded because the 'unknown' data type is used in user tables. Please remove all usages of the 'unknown' data type and try again." Below are some of the customer cases

Puede buscar el tipo de datos unknown en su base de datos y eliminar la columna o cambiar al tipo de datos a uno soportado ejecutando la siguiente sentencia SQL:

SELECT DISTINCT data_type FROM information_schema.columns where data_type ilike 'unknown';

ALTER EXTENSION POSTGIS UPDATE TO '2.2.5';

9. Durante una actualización de versión mayor, Amazon RDS también actualiza todas las réplicas de lectura de la región junto con la instancia de base de datos principal.

10. If necessary, perform scale storage to achieve 15%-20% free storage for a major version. Alternatively, enable RDS Storage autoscaling to mitigate any unforeseen space issues. Si es necesario, incremente el almacenamiento de la instancia RDS para lograr un almacenamiento disponible entre un 15 y un 20%, el mínimo recomendado para una actualización de versión mayor. También puede habilitar el escalado automático de almacenamiento en RDS para mitigar cualquier problema de espacio imprevisto.

11. Detenga cualquier tarea de DMS que dependa de la instancia de RDS que esté actualizando; para ello, defina el parámetro rds.logical_replication en 0. Cuando finalice la actualización, actualice la tabla pg_statistics ejecutando el comando SQL ANALYZE en todas las bases de datos de usuarios. Una actualización de versión mayor no mueve el contenido de la tabla pg_statistics a la nueva versión. Omitir este paso puede provocar consultas SQL lentas. También puede realizar un ensayo de actualización antes de actualizar las bases de datos de producción. Puede restaurar un snapshot de la instancia de producción y realizar una ejecución de prueba. Considere la posibilidad de probar la aplicación en la base de datos actualizada con una carga de trabajo similar para comprobar que todo funciona según lo previsto. Una vez verificada la actualización, puede eliminar esta instancia de prueba. La configuración Multi-AZ no ayuda a evitar una interrupción (tiempo fuera de línea) durante la actualización de un motor de base de datos. Multi-AZ reduce el tiempo fuera de línea durante el cambio de instancia a otro nivel de cómputo, pero dado que se requieren cambios en el nivel de almacenamiento durante la actualización del motor de base de datos, ambas instancias se actualizan al mismo tiempo. Si su base de datos es vulnerable a una interrupción, puede utilizar AWS DMS, replicación lógica o la extensión pglogical para configurar la replicación entre dos instancias principales diferentes. Cuando ambas instancias estén sincronizadas, saque las aplicaciones fuera de línea y dirija las aplicaciones a la nueva instancia maestra de RDS. También puede cambiar el nombre de la instancia en la misma región y cuenta AWS para que las aplicaciones no necesiten ningún cambio.

Resumen

AWS continúa trabajando para hacer que su experiencia de actualización de bases de datos sea más confiable y ágil. Las actualizaciones de versión en RDS PostgreSQL permiten una alta seguridad de los datos, nuevas funciones y mejor rendimiento. Si bien RDS gestiona las actualizaciones menores y mayores con un solo clic, es su responsabilidad estar al tanto de los cambios esperados en sus cargas de trabajo, de las interrupciones que se produzcan y de probar las aplicaciones en la versión de destino.

Los siguientes recursos relacionados le ayudan a comprender mejor la actualización de RDS PostgreSQL:

• Actualizando PostgreSQL con Amazon RDS
• Actualizando automáticamente versiones menores de RDS PostgreSQL

Este artigo foi traduzido do Blog da AWS em Inglês.

Acerca del autor

Vivek Singh es un Especialista de Bases de Datos Senior en Amazon Web Services enfocado en RDS/Aurora PostgreSQL. Él trabaja con clientes corporativos proveyendo asistencia técnica con PostgreSQL.

Traductor

Camilo Leon es un Arquitecto de Soluciones Principal especializado en bases de datos en Amazon Web Services radicado en San Francisco. Camilo Trabaja con clientes de AWS para proporcionar orientación y asistencia técnica en servicios de bases de datos relacionales, ayudándoles a mejorar el valor de sus soluciones cuando utilizan AWS.