Prácticas recomendadas para Amazon RDS

Descubra las prácticas recomendadas para trabajar con Amazon RDS. A medida que se identifiquen nuevas prácticas recomendadas, se actualizará esta sección.

Directrices operativas básicas de Amazon RDS

A continuación se detallan las directrices operativas básicas que se deben seguir al trabajar con Amazon RDS. El Acuerdo de nivel de servicios de Amazon RDS requiere que se sigan estas directrices:

Recomendaciones de RAM de las instancias de base de datos

Una práctica recomendada de rendimiento de Amazon RDS consiste en asignar suficiente RAM para que el conjunto de trabajo resida casi por completo en la memoria. El conjunto de trabajo son los datos e índices que se usan con frecuencia en su instancia. Cuanto más use la instancia de base de datos, más crecerá el conjunto de trabajo.

Para saber si el conjunto de trabajo está en la memoria casi en su totalidad, compruebe la métrica ReadIOPS (usando Amazon CloudWatch) mientras la instancia de base de datos está sometida a carga. El valor de ReadIOPS debe ser pequeño y estable. En algunos casos, escalar verticalmente la clase de instancia de base de datos a una clase con más RAM da como resultado una disminución brusca de ReadIOPS. En estos casos, el conjunto de trabajo no estaba casi completamente en la memoria. Siga escalando hasta que ReadIOPS no se reduzca bruscamente después de una operación de escalado o hasta que ReadIOPS se reduzca muy poco. Para obtener más información acerca de la monitorización de las métricas de las instancias de base de datos, consulte Consulta de métricas en la consola de Amazon RDS.

Controladores de bases de datos de AWS

Recomendamos el conjunto de controladores de AWS para la conectividad de las aplicaciones. Los controladores se han diseñado para permitir tiempos de transición y conmutación por error más rápidos y autenticarse con AWS Secrets Manager, AWS Identity and Access Management (IAM) e identidad federada. Los controladores de AWS se basan en la supervisión del estado de la instancia de base de datos y en el conocimiento de la topología de la instancia para determinar quién es el nuevo escritor. Este enfoque reduce los tiempos de transición y conmutación por error a segundos de un solo dígito, en comparación con las decenas de segundos de los controladores de código abierto.

A medida que se introducen nuevas características de servicio, el objetivo del conjunto de controladores de AWS es contar con soporte integrado para estas características de servicio.

Para obtener más información, consulte Conexión a instancias de base de datos con los controladores de AWS.

Uso del monitoreo mejorado para identificar los problemas del sistema operativo

Cuando el monitoreo mejorado está habilitado, Amazon RDS proporciona métricas en tiempo real para el sistema operativo (SO) en el que se ejecuta la instancia de base de datos. Puede ver las métricas de su instancia de base de datos mediante la consola. También puede consumir la salida JSON de monitoreo mejorado en Amazon CloudWatch Logs en un sistema de monitoreo de su elección. Para obtener más información acerca de la monitorización mejorada, consult Supervisión de las métricas del sistema operativo con Supervisión mejorada.

Uso de métricas para identificar los problemas de rendimiento

Para identificar los problemas de desempeño causados por la falta de recursos y otros cuellos de botella frecuentes, puede monitorizar las métricas disponibles para la instancia de base de datos de Amazon RDS.

Visualización de métricas de rendimiento

Debe monitorizar las métricas de desempeño con frecuencia para ver los valores medios, máximos y mínimos de diversos intervalos de tiempo. De este modo podrá identificar cuándo se degrada el rendimiento. También puede definir alarmas de Amazon CloudWatch para umbrales de métricas concretos si desea recibir alertas cuando se alcancen.

Para solucionar los problemas de rendimiento, es importante conocer el rendimiento de referencia del sistema. Al configurar una instancia de base de datos y ejecutarla con una carga de trabajo típica, capture los valores promedio, máximo y mínimo de todas las métricas de rendimiento. Hágalo en diferentes intervalos (por ejemplo, una hora, 24 horas, una semana o dos semanas). Esto puede darle una idea de lo que es normal. Ayuda a obtener comparaciones para las horas con picos y valles de funcionamiento. Puede usar esta información para saber cuándo cae el desempeño por debajo de los niveles estándar.

Si utiliza clústeres de base de datos Multi-AZ, supervise la diferencia de tiempo entre la última transacción en la instancia de base de datos del escritor y la última transacción aplicada en una instancia de base de datos del lector. Esta diferencia se llama retraso de réplicas. Para obtener más información, consulte Retraso de réplica y clústeres de base de datos Multi-AZ.

Puede ver las métricas combinadas de Información de rendimiento y CloudWatch en el panel de Información de rendimiento y monitorizar su instancia de base de datos. Para utilizar esta vista de monitorización, es necesario activar Información de rendimiento para la instancia de base de datos. Para obtener más información sobre la monitorización, consulte Visualización de las métricas combinadas en la consola de Amazon RDS.

Puede crear un informe de análisis de rendimiento para un período de tiempo específico y ver la información identificada y las recomendaciones para resolver los problemas. Para obtener más información, consulte, Creación de un informe de análisis de rendimiento en Información de rendimiento.

También puede ver las métricas de rendimiento usando la interfaz de línea de comandos (CLI) o la API. Para obtener más información, consulte Consulta de métricas en la consola de Amazon RDS.

La alarma aparece en la sección CloudWatch alarms (Alarmas de CloudWatch).

Evaluación de las métricas de rendimiento

Una instancia de base de datos tiene varias categorías de métricas diferentes, y la forma de determinar los valores aceptables depende de la métrica.

Para obtener descripciones individuales más detalladas de cada métrica de rendimiento disponible, consulte Supervisión de métricas de Amazon RDS con Amazon CloudWatch.

En general, los valores aceptables para las métricas de desempeño dependen del aspecto de la referencia y de lo que hace la aplicación. Investigue las variaciones coherentes o de las tendencias con respecto a la referencia. La siguiente sección ofrece algunas sugerencias sobre tipos concretos de métricas:

Para los problemas con las métricas de rendimiento, un primer paso para mejorar el rendimiento es ajustar las consultas más utilizadas y más costosas. Ajústelas para ver si hacerlo reduce la presión sobre los recursos del sistema. Para obtener más información, consulte Ajuste de consultas.

Si sus consultas están ajustadas y el problema persiste, considere la posibilidad de actualizar su Clases de instancia de base de datos de de Amazon RDS. Puede actualizarla a una con más cantidad del recurso (CPU, RAM, espacio en disco, ancho de banda de red, capacidad de E/S) relacionado con el problema.

Ajuste de consultas

Una de las formas más eficaces de mejorar el desempeño de la instancia de base de datos es ajustar las consultas más utilizadas y que más recursos consumen. Aquí, se ajustan para que sean menos costosos de ejecutar. Para obtener información sobre cómo mejorar las consultas, utilice los siguientes recursos:

Prácticas recomendadas para trabajar con MySQL

Tanto el tamaño de las tablas como el número de tablas de una base de datos MySQL pueden afectar al rendimiento.

Tamaño de las tablas

Normalmente, las restricciones del sistema operativo relativas al tamaño de los archivos determinan el tamaño máximo efectivo de las tablas para las bases de datos MySQL. Por tanto, los límites generalmente no están determinados por restricciones internas de MySQL.

En una instancia de base de datos de MySQL, evite que las tablas de la base de datos crezcan demasiado. Aunque el límite de almacenamiento general es de 64 TiB, los límites de almacenamiento aprovisionado restringen el tamaño máximo de un archivo de tabla de MySQL a 16 TiB. Divida las tablas grandes para que los tamaños de archivo estén claramente por debajo del límite de 16 TiB. Este método también puede mejorar el desempeño y el tiempo de recuperación. Para obtener más información, consulte Límites de tamaño de archivo de MySQL en Amazon RDS.

Las tablas muy grandes (de más de 100 GB de tamaño) pueden afectar negativamente al rendimiento tanto de las lecturas como de las escrituras (incluidas las instrucciones de lenguaje de manipulación de datos o DML y especialmente las instrucciones lenguaje de definición de datos o DDL). Que haya índices en tablas grandes puede aumentar considerablemente el desempeño de SELECT, pero también puede deteriorar el rendimiento de las instrucciones DML. Las instrucciones DDL, como ALTER TABLE, pueden ser considerablemente más lentas con las tablas grandes, pues con esas operaciones es posible que en algunos casos se reconstruya completamente una tabla. Con estas instrucciones DDL es posible que las tablas se bloqueen durante la duración de la operación.

La cantidad de memoria que requiere MySQL para lecturas y escrituras depende de las tablas que se impliquen en las operaciones. Es una práctica recomendada tener al menos suficiente RAM para mantener los índices de las tablas que se utilicen activamente. Para determinar cuáles son las diez tablas e índices más grandes de una base de datos, utilice la siguiente consulta:

select table_schema, TABLE_NAME, dat, idx from 
(SELECT table_schema, TABLE_NAME, 
       ( data_length ) / 1024 / 1024 as dat,
       ( index_length ) / 1024 / 1024 as idx
FROM information_schema.TABLES
order by 3 desc ) a
order by 3 desc 
limit 10;

Número de tablas

El sistema de archivos subyacente puede tener un límite en cuanto al número de archivos que representan tablas. Sin embargo, MySQL no tiene límite en el número de tablas. A parte de esto, el número total de tablas que haya en el motor de almacenamiento de InnoDB de MySQL puede contribuir al deterioro del rendimiento, independientemente del tamaño que tengan esas tablas. Para limitar el efecto del sistema operativo, puede distribuir las tablas entre varias bases de datos en la misma instancia de base de datos MySQL. Si lo hace, se podría limitar el número de archivos que hay en un directorio, pero no se resolverá el problema general.

Si hay deterioro del rendimiento debido a un número de tablas grande (más de 10 000), es a causa de que MySQL está trabajando con archivos de almacenamiento, que incluye abrirlos y cerrarlos. Para atender esta cuestión, puede aumentar el tamaño de los parámetros table_open_cache y table_definition_cache. Sin embargo, aumentar los valores de esos parámetros podría aumentar considerablemente la cantidad de memoria que usa MySQL e incluso podría agotar toda la memoria disponible. Para obtener más información, consulte How MySQL Opens and Closes Tables, en la documentación de MySQL.

Además, que haya demasiadas tablas puede afectar considerablemente el tiempo de inicio de MySQL. Es posible que afecte la posibilidad de que haya un apagado y un reinicio perfectos, así como una recuperación ante bloqueos, especialmente en versiones anteriores a MySQL 8.0.

Recomendamos tener menos de 10 000 tablas en total distribuidas entre todas las bases de datos de una instancia de base de datos. Para un caso de uso con un número de tablas grande en una base de datos MySQL, consulte One Million Tables in MySQL 8.0 (1 millón de tablas en MySQL 8.0).

Motor de almacenamiento

Las características de restauración a un momento dado y restauración de instantáneas de Amazon RDS para MySQL requieren un motor de almacenamiento que pueda recuperarse en caso de bloqueo. Estas características solo son compatibles para el motor de almacenamiento InnoDB. Aunque MySQL admite varios motores de almacenamiento con diversas capacidades, no todos están optimizados para la recuperación en caso de bloqueo y la durabilidad de los datos. Por ejemplo, el motor de almacenamiento de MyISAM no admite la recuperación fiable tras bloqueo y podría impedir que la restauración a un momento dado o la restauración de instantáneas funcionen según lo previsto. Esto podría traducirse en datos perdidos o dañados cuando MySQL se reinicia después de un bloqueo.

InnoDB es el motor de almacenamiento recomendado y admitido para las instancias de base de datos de MySQL en Amazon RDS. Las instancias de base de datos de InnoDB también se pueden migrar a Aurora, mientras que las instancias de MyISAM no se pueden migrar. Sin embargo, MyISAM funciona mejor que InnoDB si se requiere una capacidad intensiva de búsqueda de texto completo. Si a pesar de ello quiere usar MyISAM con Amazon RDS, seguir los pasos que se describen en Copias de seguridad automatizadas con motores de almacenamiento de MySQL no compatibles puede resultar útil en algunas situaciones para la funcionalidad de restauración de instantáneas.

Si desea convertir tablas de MyISAM en tablas de InnoDB, puede utilizar el proceso que se describe en Converting Tables from MyISAM to InnoDB, en la documentación de MySQL. MyISAM e InnoDB tienen diferentes fortalezas y debilidades, por lo que debe evaluar a fondo el impacto de este cambio en sus aplicaciones antes de realizarlo.

Además, no se admite el motor de almacenamiento federado para Amazon RDS for MySQL.

Prácticas recomendadas para trabajar con MariaDB

Tanto el tamaño de las tablas como el número de tablas de una base de datos de MariaDB pueden afectar al rendimiento.

Tamaño de las tablas

Normalmente, las restricciones del sistema operativo relativas al tamaño de los archivos determinan el tamaño máximo efectivo de las tablas para las bases de datos de MariaDB. Por tanto, los límites generalmente no están determinados por restricciones internas de MariaDB.

En una instancia de base de datos de MariaDB, evite que las tablas de la base de datos aumenten demasiado de tamaño. Aunque el límite de almacenamiento general es 64 TiB, debido a los límites de almacenamiento aprovisionado el tamaño máximo de un archivo de tabla de MariaDB se restringe a 16 TiB. Divida las tablas grandes para que los tamaños de archivo estén claramente por debajo del límite de 16 TiB. Este método también puede mejorar el desempeño y el tiempo de recuperación.

Las tablas muy grandes (de más de 100 GB de tamaño) pueden afectar negativamente al rendimiento tanto de las lecturas como de las escrituras (incluidas las instrucciones de lenguaje de manipulación de datos o DML y especialmente las instrucciones lenguaje de definición de datos o DDL). Que haya índices en tablas grandes puede aumentar considerablemente el desempeño de SELECT, pero también puede deteriorar el rendimiento de las instrucciones DML. Las instrucciones DDL, como ALTER TABLE, pueden ser considerablemente más lentas con las tablas grandes, pues con esas operaciones es posible que en algunos casos se reconstruya completamente una tabla. Con estas instrucciones DDL es posible que las tablas se bloqueen durante la duración de la operación.

La cantidad de memoria que requiere MariaDB para lecturas y escrituras depende de las tablas que se impliquen en las operaciones. Es una práctica recomendada tener al menos suficiente RAM para mantener los índices de las tablas que se utilicen activamente. Para determinar cuáles son las diez tablas e índices más grandes de una base de datos, utilice la siguiente consulta:

select table_schema, TABLE_NAME, dat, idx from 
(SELECT table_schema, TABLE_NAME, 
       ( data_length ) / 1024 / 1024 as dat,
       ( index_length ) / 1024 / 1024 as idx
FROM information_schema.TABLES
order by 3 desc ) a
order by 3 desc 
limit 10;

Número de tablas

El sistema de archivos subyacente puede tener un límite en cuanto al número de archivos que representan tablas. Sin embargo, MariaDB no tiene límite en el número de tablas. A parte de esto, el número total de tablas que haya en el motor de almacenamiento de InnoDB de MariaDB puede contribuir al deterioro del rendimiento, independientemente del tamaño que tengan esas tablas. Para limitar el efecto del sistema operativo, puede distribuir las tablas entre varias bases de datos en la misma instancia de base de datos de MariaDB. Si lo hace, se podría limitar el número de archivos que hay en un directorio, pero no se resuelve el problema general.

Si hay deterioro del rendimiento debido a un número de tablas grande (más de 10 000), es a causa de que MariaDB está trabajando con archivos de almacenamiento. Este trabajo incluye que MariaDB abra y cierre archivos de almacenamiento. Para atender esta cuestión, puede aumentar el tamaño de los parámetros table_open_cache y table_definition_cache. Sin embargo, aumentar los valores de esos parámetros podría aumentar considerablemente la cantidad de memoria que usa MariaDB. Incluso podría usar toda la memoria disponible. Para obtener más información, consulte Optimizing table_open_cache, en la documentación de MariaDB.

Además, que haya demasiadas tablas puede afectar considerablemente el tiempo de inicio de MariaDB. Es posible que afecte la posibilidad de que haya un apagado y un reinicio perfectos, así como una recuperación ante bloqueos. Recomendamos tener menos de 10 000 tablas en total distribuidas entre todas las bases de datos de una instancia de base de datos.

Motor de almacenamiento

Las características de restauración a un momento dado y restauración de instantáneas de Amazon RDS for MariaDB requieren un motor de almacenamiento que pueda recuperarse en caso de bloqueo. Aunque MariaDB admite varios motores de almacenamiento con diversas capacidades, no todos están optimizados para la recuperación en caso de bloqueo y la durabilidad de los datos. Por ejemplo, aunque Aria es un sustituto a prueba de bloqueos para MyISAM, también podría impedir que la restauración a un momento dado o la restauración de instantáneas funcionen según lo previsto. Esto podría traducirse en datos perdidos o dañados cuando MariaDB se reinicia después de un bloqueo. InnoDB es el motor de almacenamiento recomendado y admitido para las instancias de base de datos de MariaDB en Amazon RDS. Si a pesar de ello quiere usar Aria con Amazon RDS, seguir los pasos que se describen en Copias de seguridad automatizadas con motores de almacenamiento de MariaDB no compatibles puede resultar útil en algunas situaciones para la funcionalidad de restauración de instantáneas.

Si desea convertir tablas de MyISAM en tablas de InnoDB, puede utilizar el proceso que se describe en Converting Tables from MyISAM to InnoDB en la documentación de MariaDB. MyISAM e InnoDB tienen diferentes fortalezas y debilidades, por lo que debe evaluar a fondo el impacto de este cambio en sus aplicaciones antes de realizarlo.

Prácticas recomendadas para trabajar con Oracle

Para obtener información sobre las prácticas recomendadas para trabajar con Amazon RDS for Oracle, consulte Prácticas recomendadas para ejecutar Oracle Database en Amazon Web Services.

Un taller virtual de AWS de 2020 incluyó una presentación sobre la ejecución de bases de datos de Oracle de producción en Amazon RDS. Puede ver aquí un vídeo de la presentación:

Prácticas recomendadas para trabajar con PostgreSQL

De las dos áreas importantes en las que puede mejorar el rendimiento con RDS para PostgreSQL, una es la carga de datos en una instancia de base de datos. Otra es cuando se utiliza la característica autovacuum de PostgreSQL. Las siguientes secciones tratan algunas de las prácticas recomendadas para esas áreas.

Para obtener información sobre cómo Amazon RDS implementa otras tareas comunes de DBA de PostgreSQL, consulte Tareas comunes de los administradores de base de datos (DBA) para Amazon RDS para PostgreSQL.

Carga de datos en una instancia de base de datos de PostgreSQL

Cuando se cargan datos en una instancia de base de datos de Amazon RDS para PostgreSQL, se debe modificar la configuración de la instancia de base de datos y los valores del grupo de parámetros de base de datos. Configúrelos para permitir la importación más eficiente de datos a su instancia de base de datos.

Modifique la configuración de su instancia de base de datos como se indica a continuación:

Modifique el grupo de parámetros de base de datos para incluir la siguiente configuración. Asimismo, pruebe la configuración de los parámetros para encontrar los ajustes más eficientes para su instancia de base de datos.

Use los comandos pg_dump -Fc (comprimido) o pg_restore -j (paralelo) con estos ajustes.

Una vez finalizada la operación de carga, devuelva la instancia de base de datos y los parámetros de base de datos a su configuración normal.

Trabajo con la característica autovacuum de PostgreSQL

La característica autovacuum de las bases de datos de PostgreSQL es una función cuyo uso se recomienda para mantener la instancia de base de datos de PostgreSQL en buen estado. Autovacuum automatiza la ejecución de los comandos VACUUM y ANALYZE. El uso de autovacuum es requerido por PostgreSQL, no impuesto por Amazon RDS, y es esencial para un buen desempeño. La característica está habilitada de manera predeterminada para todas las nuevas instancias de base de datos de Amazon RDS para PostgreSQL, y los parámetros de configuración relacionados se definen correctamente de forma predeterminada.

El administrador de la base de datos debe conocer y entender esta operación de mantenimiento. Para obtener la documentación de PostgreSQL sobre autovacuum, consulte The Autovacuum Daemon.

Autovacuum no es una operación que no consuma recursos, pero funciona en segundo plano y deja a las operaciones del usuario toda la capacidad posible. Cuando está habilitado, autovacuum busca las tablas en las que se ha insertado, actualizado o eliminado un número elevado de tuplas. También protege contra la pérdida de los datos muy antiguos debida al reinicio de los ID de transacciones. Para obtener más información, consulte Preventing Transaction ID Wraparound Failures.

Autovacuum no se debe entender como una operación de alto consumo que se puede reducir para mejorar el desempeño. Por el contrario, las tablas con una velocidad alta de actualizaciones y eliminaciones se deteriorarán con rapidez si no se ejecuta autovacuum.

Los parámetros de autovacuum determinan cuándo y con qué intensidad funciona autovacuum. Los parámetrosautovacuum_vacuum_threshold y autovacuum_vacuum_scale_factor determinan cuándo se ejecuta autovacuum. Los parámetros autovacuum_max_workers, autovacuum_nap_time, autovacuum_cost_limit y autovacuum_cost_delay determinan la intensidad con la que trabaja autovacuum. Para obtener más información acerca de autovacuum, de cuándo se ejecuta y de los parámetros que requiere, consulte Routine Vacuuming en la documentación de PostgreSQL.

La siguiente consulta muestra el número de tuplas “muertas” en una tabla denominada table1:

SELECT relname, n_dead_tup, last_vacuum, last_autovacuum FROM 
pg_catalog.pg_stat_all_tables 
WHERE n_dead_tup > 0 and relname = 'table1';

Los resultados de la consulta serán similares a los siguientes:

relname | n_dead_tup | last_vacuum | last_autovacuum
---------+------------+-------------+-----------------
 tasks   |   81430522 |             |
(1 row) 

Video de prácticas recomendadas de Amazon RDS for PostgreSQL

La conferencia de AWS re:Invent de 2020 incluyó una presentación sobre nuevas características y prácticas recomendadas para trabajar con PostgreSQL en Amazon RDS. Puede ver aquí un vídeo de la presentación:

Prácticas recomendadas para trabajar con SQL Server

Entre las prácticas recomendadas para un despliegue Multi-AZ con una instancia de base de datos de SQL Server se incluyen las siguientes:

Cuando trabaje con una implementación Multi-AZ de SQL Server, recuerde que Amazon RDS crea réplicas para todas las bases de datos de SQL Server de su instancia. Si no desea que determinadas bases de datos tengan réplicas secundarias, configure una instancia de base de datos independiente que no use Multi-AZ para esas bases de datos.

Video de prácticas recomendadas de Amazon RDS for SQL Server

La conferencia de AWS re:Invent de 2019 incluyó una presentación sobre nuevas características y prácticas recomendadas para trabajar con SQL Server en Amazon RDS. Puede ver aquí un vídeo de la presentación:

Trabajo con los grupos de parámetros de base de datos

Es recomendable que pruebe los cambios de los grupos de parámetros de base de datos en una instancia de base de datos de prueba antes de aplicarlos en las instancias de base de datos de producción. Si se configuran de forma incorrecta los parámetros del motor de base de datos de un grupo de parámetros de base de datos, pueden producirse efectos adversos no deseados, como la degradación del desempeño y la inestabilidad del sistema. Tenga cuidado siempre que modifique los parámetros del motor de base de datos y cree una copia de seguridad de la instancia de base de datos antes de modificar un grupo de parámetros de base de datos.

Para obtener información acerca del procedimiento para realizar la copia de seguridad de la instancia de base de datos, consulte Copia de seguridad, restauración y exportación de datos.

Prácticas recomendadas para automatizar la creación de instancias de base de datos

Es una práctica recomendada de Amazon RDS crear una instancia de base de datos con la versión secundaria preferida del motor de base de datos. Puede utilizar la AWS CLI, la API de Amazon RDS o la AWS CloudFormation para automatizar la creación de una instancia de base de datos. Cuando utiliza estos métodos, solo puede especificar la versión principal y Amazon RDS crea automáticamente la instancia con la versión secundaria preferida. Por ejemplo, si PostgreSQL 12.5 es la versión secundaria preferida y si especifica la versión 12 con create-db-instance, la instancia de base de datos será la versión 12.5.

Para determinar la versión secundaria preferida, puede ejecutar el comando describe-db-engine-versions con la opción --default-only que se muestra en el siguiente ejemplo.

aws rds describe-db-engine-versions --default-only --engine postgres

{
    "DBEngineVersions": [
        {
            "Engine": "postgres",
            "EngineVersion": "12.5",
            "DBParameterGroupFamily": "postgres12",
            "DBEngineDescription": "PostgreSQL",
            "DBEngineVersionDescription": "PostgreSQL 12.5-R1",
            ...some output truncated...
        }
    ]
}

Para obtener información sobre la creación de instancias de base de datos mediante programación, consulte los siguientes recursos:

Vídeo de nuevas características de Amazon RDS

La conferencia de AWS re:Invent de 2023 incluyó una presentación sobre nuevas características de Amazon RDS. Puede ver aquí un vídeo de la presentación: