Preguntas frecuentes de Amazon RDS para PostgreSQL

Sí, puede adquirir un Savings Plans para bases de datos para su uso de Amazon RDS para PostgreSQL y reducir los costos hasta en un 20 % si se compromete a una cantidad constante de uso durante un periodo de 1 año. Puede encontrar información adicional sobre el uso elegible en la página de precios de los Savings Plans para bases de datos.

Actualmente, Amazon RDS para PostgreSQL es compatible con las versiones 13, 14, 15, 16 y 17 de PostgreSQL. RDS para PostgreSQL también es compatible con PostgreSQL 11 y 12 mediante el soporte ampliado de Amazon RDS. Para obtener más información, consulte la guía del usuario de Amazon RDS.

Puede consultar una lista de extensiones admitidas en la guía del usuario de Amazon RDS. Si desea solicitar que se admitan extensiones adicionales, puede enviar un correo electrónico a rds-postgres-extensions-request@amazon.com con el nombre de la extensión y el caso de uso.

RDS para PostgreSQL admite varios parámetros para registrar la actividad que se produce en su instancia de base de datos PostgreSQL. Puede obtener más información sobre ellos en la guía del usuario de Amazon RDS.

Sí, puede leer sobre las limitaciones de las instancias de RDS para PostgreSQL en la guía del usuario de Amazon RDS.

En el contexto de RDS para PostgreSQL, los números de versión se organizan de la siguiente forma: versión de PostgreSQL = X.Y-R(n).

Desde el punto de vista de Amazon RDS, un cambio de versión se considera principal si se modifica la primera parte del número de versión. Ejemplo: cambio de 15.9 a 17.1.

Un cambio de versión se considera secundario si se modifica la segunda parte del número de versión. Ejemplo: cambio de 17.1 a 17.2.

R(n) indica la versión posterior de una versión secundaria que puede incluir nuevas características, mejoras de rendimiento y correcciones de errores. Una versión secundaria puede o no tener la versión R(n). Ejemplo: cambio de 17.1 a 17.1-R2 o 17.1-R3

Consulte la política de control de versiones de PostgreSQL para obtener más información.

Sí, consulte las preguntas frecuentes de Amazon RDS para obtener información sobre el control de versiones.

Extensiones de lenguaje de confianza (TLE) para PostgreSQL permite a los desarrolladores crear extensiones de alto rendimiento y ejecutarlas de forma segura en Amazon RDS. Al hacerlo, TLE mejora su tiempo de comercialización y elimina la carga impuesta a los administradores de bases de datos para certificar el código personalizado y de terceros para su uso en cargas de trabajo de bases de datos de producción. Puede avanzar tan pronto como decida que una extensión satisface sus necesidades. Con TLE, los proveedores de software independientes (ISV) pueden proporcionar a los clientes nuevas extensiones de PostgreSQL que se ejecutan en Amazon RDS.

Las extensiones de PostgreSQL se ejecutan en el mismo espacio de proceso para otorgar un alto rendimiento. Sin embargo, las extensiones pueden tener defectos de software que pueden bloquear la base de datos. 

TLE para PostgreSQL ofrecen múltiples capas de protección para mitigar este riesgo. TLE está diseñado para limitar el acceso a los recursos del sistema. El rol rds_superuser puede determinar quién tiene permiso para instalar extensiones específicas. Sin embargo, estos cambios solo se pueden llevar a cabo a través de la API de TLE. TLE está diseñado para limitar el impacto de un defecto de extensión a una única conexión de base de datos. Además de estas medidas de seguridad, TLE está diseñado para proporcionar a los administradores de bases de datos (DBA) en el rol rds_superuser un control en línea detallado sobre quién puede instalar extensiones y pueden crear un modelo de permisos para ejecutarlas.

Solo los usuarios con suficientes privilegios podrán ejecutar y crear con el comando “CREATE EXTENSION” en una extensión de TLE. Los DBA también pueden incluir en la lista de permitidos los “enlaces de PostgreSQL” necesarios para extensiones más sofisticadas que modifican el comportamiento interno de la base de datos y, por lo general, requieren privilegios elevados.

Aurora y Amazon RDS admiten un conjunto seleccionado de más de 85 extensiones de PostgreSQL. AWS administra los riesgos de seguridad para cada una de estas extensiones bajo el Modelo de responsabilidad compartida de AWS. La extensión que implementa TLE para PostgreSQL se incluye en este conjunto. Las extensiones que escribe o que obtiene de fuentes de terceros e instala en TLE se consideran parte del código de su aplicación. Usted es responsable de la seguridad de sus aplicaciones que usan extensiones de TLE.

Puede crear funciones de desarrollador, como compresión de mapa de bits y privacidad diferencial (como consultas estadísticas de acceso público que protegen la privacidad de las personas).

 Actualmente, TLE admite la creación de extensiones en JavaScript, Perl, Tcl, PL/pgSQL y SQL. 

Una vez que el rol rds_superuser activa TLE para PostgreSQL, puede implementar extensiones de TLE mediante el comando SQL CREATE EXTENSION desde cualquier cliente de PostgreSQL, como psql. Esto es similar a cómo crearía una función definida por el usuario escrita en un lenguaje de procedimiento, como PL/pgSQL o PL/Perl. Puede controlar qué usuarios tienen permiso para implementar extensiones de TLE y usar extensiones específicas.

TLE para PostgreSQL accede a su base de datos PostgreSQL exclusivamente a través de la API de TLE. Los lenguajes de confianza admitidos por TLE incluyen todas las funciones de la interfaz de programación del servidor (SPI) de PostgreSQL y compatibilidad con enlaces de PostgreSQL, incluido el enlace de verificación de contraseña.

Puede obtener más información sobre el proyecto TLE para PostgreSQL en la página oficial de TLE de GitHub.

Para RDS para PostgreSQL, las implementaciones azul/verde son compatibles con la versión 11.1 y todas las versiones principales y secundarias posteriores. Para obtener más información, consulte Regiones y motores de base de datos admitidos para implementaciones azul/verde de Amazon RDS. 

Las implementaciones azul/verde de Amazon RDS le permiten hacer cambios de bases de datos con mayor seguridad, sencillez y rapidez. Las implementaciones azul-verde son ideales para casos de uso como actualizaciones del motor de bases de datos de versiones principales o secundarias, actualizaciones del sistema operativo, cambios de esquema en entornos verdes que no interrumpen la replicación lógica, como agregar una nueva columna al final de una tabla o cambios en la configuración de los parámetros de la base de datos.

Puede utilizar las implementaciones azul-verde para realizar varias actualizaciones de bases de datos al mismo tiempo mediante una sola conmutación. Esto le permite mantenerse al día con las revisiones de seguridad, mejorar el rendimiento de la base de datos y acceder a las características más recientes de la base de datos con un tiempo de inactividad breve y predecible.

Las implementaciones azul/verde de Amazon RDS le permiten hacer cambios de bases de datos más seguros, simples y rápidos, como actualizaciones de versiones principales o secundarias, cambios de esquema, escalado de instancias, cambios de parámetros del motor y actualizaciones de mantenimiento.

En las implementaciones azul/verde de Amazon RDS, el entorno azul es el entorno de producción actual. El entorno verde es el entorno de ensayo, que será el nuevo entorno de producción después de la transición.

Cuando las implementaciones azul/verde de Amazon RDS inician una transición, se bloquean las escrituras en los entornos azul y verde hasta que se completa la transición. Durante la conmutación, el entorno de ensayo, o entorno verde, se actualiza con el sistema de producción, lo que garantiza que los datos sean coherentes entre el entorno de ensayo y el de producción.

Una vez que los entornos de producción y ensayo están completamente sincronizados, las implementaciones azul/verde promocionan el entorno de ensayo como entorno de producción al redirigir el tráfico al entorno de producción recién promocionado. Las implementaciones azul/verde están diseñadas para permitir escrituras en el entorno verde después de que se completa la transición, lo que garantiza que no se pierdan datos durante el proceso de transición.

Si su entorno azul es una réplica lógica autoadministrada o un suscriptor, bloquearemos la transición. Se recomienda detener primero la replicación en el entorno azul, continuar con la conmutación y, a continuación, reanudar la replicación. Por el contrario, si su entorno azul es el origen de una réplica lógica autoadministrada o un editor, puede continuar con la conmutación. Sin embargo, tendrá que actualizar la réplica autoadministrada para replicarla desde el entorno verde después de la transición.

Las implementaciones azul/verde de Amazon RDS no eliminan su antiguo entorno de producción. Si es necesario, puede acceder a él para validaciones adicionales y pruebas de rendimiento o regresión. Si ya no necesita el antiguo entorno de producción, puede eliminarlo. Los cargos de facturación estándar se aplican a las instancias de producción antiguas hasta que las elimine.

Las barreras de protección de transición de las implementaciones azul/verde de Amazon RDS bloquean las escrituras en los entornos azul y verde hasta que el entorno verde se actualiza antes de la transición. Las implementaciones azul-verde también realizan comprobaciones de estado del entorno principal y las réplicas en los entornos azul y verde. Además, realizan comprobaciones del estado de la replicación, por ejemplo, para ver si la replicación se ha detenido o si hay errores.

Detectan transacciones de ejecución prolongada entre los entornos azul y verde. Puede especificar un tiempo de inactividad máximo tolerable, a partir de 30 segundos, y si tiene una transacción en curso que lo excede, la transición se interrumpirá.

No, las implementaciones azul/verde de Amazon RDS no admiten Amazon RDS Proxy, réplicas de lectura entre regiones ni réplicas de lectura en cascada.

No, en este momento no puede utilizar las implementaciones azul/verde de Amazon RDS para revertir los cambios.

Amazon DevOps Guru para RDS es una nueva capacidad basada en ML para Amazon RDS para PostgreSQL (que incluye a Amazon Aurora), que está diseñada para detectar y diagnosticar de forma automática el rendimiento de la base de datos y los problemas operativos, lo que permite resolver problemas en minutos en lugar de días.

Amazon DevOps Guru para RDS es una característica de Amazon DevOps Guru, que está diseñada para detectar problemas operativos y de rendimiento para todos los motores de Amazon RDS y docenas de otros tipos de recursos. DevOps Guru para RDS amplía las capacidades existentes de DevOps Guru para detectar, diagnosticar y remediar una amplia variedad de problemas relacionados con la base de datos en Amazon RDS para PostgreSQL (como el uso excesivo de recursos y el mal comportamiento de determinadas consultas de SQL).

Cuando surge un problema, Amazon DevOps Guru para RDS está diseñado para notificar de manera inmediata a los desarrolladores y los ingenieros de DevOps y proporciona información de diagnóstico, detalles sobre el alcance del problema y recomendaciones de corrección inteligente para ayudar a los clientes a resolver rápidamente cuellos de botella de rendimiento relacionados con la base de datos y problemas operativos.

Amazon DevOps Guru para RDS está diseñado para eliminar el esfuerzo manual y ahorrar tiempo (de horas y días a minutos) para detectar y resolver cuellos de botella de rendimiento difíciles de encontrar en la carga de trabajo de la base de datos relacional.

Puede habilitar DevOps Guru para RDS para cada base de datos de Amazon RDS para PostgreSQL, el cual detectará de forma automática problemas de rendimiento de sus cargas de trabajo, enviará alertas sobre cada problema, explicará los hallazgos y recomendará acciones para resolver los problemas.

DevOps Guru para RDS ayuda a que la administración de bases de datos sea más accesible para quienes no son expertos y ayuda a los expertos de bases de datos para que puedan administrar aún más bases de datos.

Amazon DevOps Guru para RDS utiliza ML para analizar los datos de telemetría recopilados por Información de rendimiento (PI) de Amazon RDS. DevOps Guru para RDS no utiliza ninguno de los datos almacenados en la base de datos durante su análisis. DevOps Guru para RDS busca patrones problemáticos en la telemetría de PI mediante una combinación de reglas y técnicas basadas en ML, y alerta a los clientes cuando se detectan dichos patrones.

Para comenzar a utilizar DevOps Guru para RDS, asegúrese de que la característica Información de rendimiento esté habilitada a través de la consola de Amazon RDS y simplemente habilite DevOps Guru para las bases de datos de Amazon RDS para PostgreSQL. Con DevOps Guru, puede elegir que el límite de cobertura de análisis sea toda su cuenta de AWS, prescribir las pilas de AWS CloudFormation específicas que desea que DevOps Guru analice o utilizar etiquetas de AWS para crear la agrupación de recursos que desea que DevOps Guru analice.

Amazon DevOps Guru para RDS ayuda a identificar una amplia variedad de problemas de rendimiento que pueden afectar la calidad del servicio de la aplicación, como bloqueos acumulados, tormentas de conexión, regresiones SQL, contención de CPU y E/S, problemas de memoria o parámetros mal configurados.

Información de rendimiento de Amazon RDS es una característica de ajuste y supervisión del rendimiento de las bases de datos que recopila y ofrece una representación visual de las métricas de rendimiento de la base de datos de Amazon RDS, lo que ayuda a evaluar de forma rápida el estado de las bases de datos y determinar cuándo y dónde tomar las medidas oportunas. Amazon DevOps Guru para RDS está diseñado para supervisar esas métricas, detectar cuándo la base de datos está experimentando problemas de rendimiento, analizar las métricas y, luego, decirle qué está mal y qué puede hacer al respecto.