Administración de recuentos de objetos altos en Amazon RDS para 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.

Error: “No hay suficientes descriptores de archivos: hay demasiados archivos abiertos en el sistema; libérelos y vuelva a intentarlo”. El parámetro max_files_per_process de PostgreSQL determina cuántos archivos puede abrir cada proceso. Si hay un número elevado de conexiones que se unen a un número elevado de tablas, es posible alcanzar este límite.

Acción recomendada:

Error: “Falta de espacio en el dispositivo”. Si esto se observa cuando hay suficiente espacio libre de almacenamiento, se debe a que se están agotando los inodos. La Supervisión mejorada de Amazon RDS proporciona visibilidad de los inodos en uso y del número máximo disponible para el host.

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.

Durante cualquier estado de la base de datos que implique la recuperación de errores de la base de datos, como el reinicio multi-AZ con conmutación por error, la recuperación en un momento dado de Amazon RDS y la actualización de la versión principal de Amazon RDS, se producirá la operación serializada de truncar las tablas no registradas. Esto puede provocar un tiempo de inactividad mucho mayor de lo esperado.

Acción recomendada:

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:

Error: “No hay suficientes descriptores de archivos: hay demasiados archivos abiertos en el sistema; libérelos y vuelva a intentarlo”. El parámetro max_files_per_process de PostgreSQL determina cuántos archivos puede abrir cada proceso. Si hay un número elevado de conexiones que se unen a un número elevado de tablas, es posible alcanzar este límite.

Acción recomendada:

Error: “Falta de espacio en el dispositivo”. Si esto se observa cuando hay suficiente espacio libre de almacenamiento, se debe a que se están agotando los inodos. La Supervisión mejorada de Amazon RDS proporciona visibilidad de los inodos en uso y del número máximo disponible para el host.

Si planea usar Implementaciones azules/verdes de Amazon RDS 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.