Administración de recuentos de objetos altos en Amazon Aurora PostgreSQL

La limpieza automática puede tener dificultades para mantenerse al día con el crecimiento de ID de transacciones o la sobrecarga de la tabla debido a la falta de personal en comparación con la cantidad de trabajo.

Acción recomendada: existen varios factores para ajustar la limpieza automática a fin de que pueda funcionar correctamente con un número determinado de tablas y una carga de trabajo determinada. Consulte Prácticas recomendadas para trabajar con la limpieza automática de PostgreSQL para obtener sugerencias sobre cómo determinar la configuración de limpieza automática adecuada. Utilice la utilidad postgres_get_av_diag para supervisar los problemas relacionados con el crecimiento de ID de transacción.

Amazon RDS utiliza la opción “--link” durante la ejecución de pg_upgrade para evitar tener que hacer copias de los archivos de datos. Aun así, es necesario restaurar los metadatos del esquema en la nueva versión de la base de datos. Incluso con pg_restore paralelo, si hay un número significativo de relaciones, esto aumentará la cantidad de tiempo de inactividad.

Degradación general del rendimiento debido al tamaño del catálogo. Cada tabla y sus columnas asociadas se agregarán a las tablas de pg_attribute, pg_class y pg_depend que se utilizan con frecuencia en las operaciones normales de la base de datos. No habrá ningún evento de espera específico visible, pero la eficiencia del búfer compartido se verá afectada.

Acción recomendada: compruebe con regularidad la sobrecarga de la tabla para estas tablas específicas y, de vez en cuando, realice una operación VACUUM FULL en estas tablas específicas. Tenga en cuenta que VACUUM FULL en las tablas del catálogo requiere un bloqueo ACCESS EXCLUSIVE, lo que significa que ninguna otra consulta podrá acceder a ellas hasta que se complete la operación.

Las tablas temporales no se aspiran con limpieza automática, sino que conservan los ID de las transacciones durante su existencia y, si no se retiran, pueden quedar ocultas.

Acción recomendada: las tablas temporales permanecerán activas mientras dure la sesión en la que se crearon o se pueden eliminar manualmente. Una práctica recomendada consiste en evitar las transacciones de larga duración con tablas temporales para evitar que estas tablas contribuyan al máximo crecimiento de los ID de transacción utilizados.

Degradación general del rendimiento debido al tamaño del catálogo. Cuando las sesiones crean y descartan tablas temporales de forma continua, se agregan a tablas de pg_attribute, pg_class y pg_depend que se utilizan con frecuencia en las operaciones normales de la base de datos. No habrá ningún evento de espera específico visible, pero la eficiencia del búfer compartido se verá afectada.

Acción recomendada:

Por lo general, las tablas no registradas no se incluyen en la replicación lógica, como implementaciones azul/verde, porque la replicación lógica se basa en WAL para capturar y transferir los cambios. Obtenga más información sobre cómo configurar Aurora PostgreSQL para replicar tablas no registradas.

Solo puede acceder a las tablas no registradas desde el nodo de escritura del clúster de base de datos de Aurora. Consulte Trabajo con tablas no registradas en Aurora PostgreSQL para obtener todos los detalles.

A veces, la sobrecarga de tiempo de planificación aumentará y la explicación de los planes para las consultas se volverá más complicada, lo que dificultará la identificación de las oportunidades de ajuste. En el caso de las versiones de PostgreSQL anteriores a la 18, muchas particiones con una gran carga de trabajo pueden provocar esperas de LWLock:LockManager.

Acción recomendada: determine un número mínimo de particiones que permita completar la organización de los datos y, al mismo tiempo, ejecutar las consultas de forma eficaz.

Un número muy elevado de particiones provocará dificultades de mantenimiento, como la creación previa y la eliminación. La limpieza automática tratará las particiones como si fueran relaciones normales y tendrá que realizar una limpieza periódica, por lo que necesitará un número suficiente de trabajadores para completar la tarea.

Acción recomendada:

Los archivos temporales son una parte necesaria de PostgreSQL cuando los resultados de las consultas no caben en work_mem. Está bien en general. Sin embargo, cuando la carga de trabajo lo utiliza mucho, eso indica que se están ejecutando consultas de gran tamaño de forma continua y se observará una disminución del uso de FreeLocalStorage. Consulte Administración de archivos temporales para obtener más información.

Si planea usar Implementaciones azules/verdes para cualquier tipo de cambio o actualización de configuración, es importante que comprenda el impacto de un gran número de secuencias en la conmutación. Una de las últimas fases de la conmutación sincronizará el valor actual de las secuencias y, si hay varios miles, aumentará el tiempo total de conmutación.

Acción recomendada: si la carga de trabajo de la base de datos permitiera el uso de un UUID compartido en lugar de un enfoque de secuencia por tabla, esto reduciría el paso de sincronización durante una conmutación.

Los objetos grandes no se replican actualmente en PostgreSQL durante la replicación lógica. Para obtener más información, consulte Página de restricciones en la documentación de PostgreSQL. En una configuración azul/verde, esto significa que los objetos grandes del entorno azul no se replican en el entorno verde.

Una actualización puede quedarse sin memoria y fallar si hay millones de objetos grandes y la instancia no puede gestionarlos durante una actualización. El proceso de actualización a la versión principal de PostgreSQL consta de dos amplias fases: el volcado del esquema a través de pg_dump y la restauración de este a través de pg_restore. Si su base de datos tiene millones de objetos de gran tamaño, debe asegurarse de que la instancia tenga memoria suficiente para gestionar pg_dump y pg_restore durante una actualización y escalarla a un tipo de instancia más grande.