Motores y clases de instancia de RDS

Amazon RDS admite seis motores de bases de datos: MySQL, PostgreSQL, MariaDB, Oracle, Microsoft SQL Server y Amazon Aurora. Cada motor es una versión completamente administrada de la base de datos de código abierto o comercial que ya conoce. AWS se encarga de la aplicación de parches, las copias de seguridad y la conmutación por error, para que usted pueda centrarse en la lógica de su aplicación.

La elección del motor adecuado depende de los requisitos de su aplicación actual, los costes de las licencias y las características que ofrece cada motor. Aurora es la opción nativa de la nube de AWS, diseñada para ofrecer rendimiento y disponibilidad.

MySQL es la base de datos relacional de código abierto más popular del mundo y resulta una opción natural para aplicaciones web y CMS. PostgreSQL ofrece un cumplimiento avanzado de SQL, una sólida compatibilidad con JSONB y un potente ecosistema de extensiones, por lo que es popular para cargas de trabajo de análisis y geoespaciales.

Ambos motores en RDS admiten copias de seguridad automatizadas, implementaciones Multi-AZ y réplicas de lectura. Las réplicas de lectura de PostgreSQL pueden abarcar varias regiones, mientras que MySQL admite hasta 15 réplicas entre regiones con Aurora MySQL.

MariaDB es una bifurcación de MySQL desarrollada por la comunidad, totalmente compatible con los clientes de MySQL a nivel de protocolo de red. Ofrece motores de almacenamiento adicionales, un mejor rendimiento en algunas cargas de trabajo y un modelo de desarrollo abierto sin características propietarias.

En RDS, MariaDB es un reemplazo directo de MySQL si desea evitar las licencias de MySQL de Oracle o prefiere la bifurcación de la comunidad. Admite las mismas funciones de copias de seguridad automatizadas, Multi-AZ y réplicas de lectura que MySQL.

Oracle Database en RDS admite los modelos License Included (LI) y Bring Your Own License (BYOL). LI incluye la licencia de Oracle SE2 en la tarifa por hora, mientras que BYOL permite utilizar su licencia existente de Enterprise Edition para funciones como la partición y Advanced Security.

Microsoft SQL Server en RDS también ofrece ediciones LI (Express, Web, Standard y Enterprise) y BYOL. Ambos motores admiten Multi-AZ con replicación síncrona, pero no admiten réplicas de lectura del mismo modo que los motores de código abierto.

Amazon Aurora es una base de datos relacional nativa de la nube compatible con MySQL y PostgreSQL. Aurora ofrece hasta 5 veces el rendimiento de MySQL y 3 veces el rendimiento de PostgreSQL en el mismo hardware, gracias a una capa de almacenamiento distribuido que replica automáticamente los datos seis veces en tres zonas de disponibilidad.

El almacenamiento de Aurora aumenta automáticamente en incrementos de 10 GB hasta 128 TiB, lo que elimina la necesidad de aprovisionarlo manualmente. La separación entre cómputo y almacenamiento también permite que Aurora Serverless escale automáticamente la capacidad hacia arriba o hacia abajo.

Las clases de instancia de RDS siguen la misma convención de nombres que EC2, pero llevan el prefijo db. en lugar de únicamente la letra de la familia. Las familias principales son:

• db.t — Rendimiento ampliable, rentable para desarrollo y pruebas (por ejemplo, db.t3.micro, db.t4g.small)
• db.m — Propósito general, con un equilibrio entre CPU y memoria (por ejemplo, db.m6g.large)
• db.r — Optimizada para memoria, para cachés grandes y tablas en memoria (por ejemplo, db.r6g.xlarge)
• db.x — Memoria extrema para Oracle y SQL Server con cargas de trabajo de SAP

Elija db.t para desarrollo, db.m para producción habitual y db.r para bases de datos con conjuntos de trabajo grandes.

Para seleccionar una clase de instancia de RDS debe analizar la utilización de CPU, el consumo de memoria, las necesidades de IOPS y el ancho de banda de red de su carga de trabajo. AWS Compute Optimizer y la herramienta RDS Performance Insights ayudan a determinar si su instancia actual está sobredimensionada o insuficientemente aprovisionada.

Un patrón habitual consiste en comenzar con una db.t3 para crear prototipos, pasar a db.m6g cuando la carga se estabiliza y cambiar a db.r6g cuando las consultas se benefician de un buffer pool más grande. Las instancias basadas en Graviton2 (db.m6g, db.r6g) suelen ofrecer hasta un 35 % más de relación precio-rendimiento que sus equivalentes x86.

RDS ofrece tres tipos de almacenamiento que se corresponden internamente con volúmenes de EBS:

• gp2 / gp3 — SSD de propósito general; gp3 permite aprovisionar IOPS y rendimiento de forma independiente sin pagar por almacenamiento adicional
• io1 / io2 — SSD con IOPS aprovisionadas para bases de datos OLTP sensibles a la latencia que requieren una respuesta constante inferior a un milisegundo
• st1 — HDD optimizado para rendimiento, disponible únicamente para determinados motores y cargas de trabajo de prueba

Para la mayoría de las implementaciones de RDS en producción, gp3 es la opción predeterminada recomendada, ya que ofrece 3.000 IOPS sin coste adicional y puede escalarse independientemente del tamaño del almacenamiento.

RDS admite dos dimensiones de escalado. El escalado vertical (cambio de clase de instancia) requiere un breve periodo de inactividad, a menos que Multi-AZ esté habilitado; con Multi-AZ, la conmutación por error permite que el cambio de tamaño se realice con un tiempo de inactividad casi nulo. Puede programar la modificación para la próxima ventana de mantenimiento o aplicarla inmediatamente.

El escalado horizontal es de solo lectura: añade réplicas de lectura para distribuir las consultas SELECT y alejarlas de la instancia principal. Las réplicas de lectura utilizan replicación asíncrona, por lo que existe un pequeño retraso de replicación que su aplicación debe tolerar.

Al elegir entre Aurora y MySQL/PostgreSQL de la comunidad, tenga en cuenta estas ventajas y desventajas:

• Aurora: mayor rendimiento, replicación automática en 6 copias, conmutación por error rápida (~30 s), sin gestión manual del almacenamiento y mayor coste por hora
• MySQL/PostgreSQL: menor coste, más extensiones de la comunidad, opción BYOL y herramientas operativas conocidas

En los escenarios de examen, se prefiere Aurora cuando la pregunta hace hincapié en la alta disponibilidad, el crecimiento automático del almacenamiento o un rendimiento cercano al de las bases de datos comerciales a un precio de código abierto. Los motores de la comunidad son la mejor opción cuando la prioridad es minimizar costes o lograr la paridad de características con las implementaciones locales.

RDS distingue entre actualizaciones de versiones menores (por ejemplo, MySQL 8.0.32 → 8.0.36) y actualizaciones de versiones principales (por ejemplo, MySQL 5.7 → 8.0). Las actualizaciones menores se pueden configurar para que se apliquen automáticamente durante la ventana de mantenimiento mediante la activación de --auto-minor-version-upgrade. Las actualizaciones principales son manuales y pueden requerir pruebas de compatibilidad de la aplicación.

Pruebe siempre primero las actualizaciones de versiones principales en un entorno de preparación. Puede crear una instantánea de la base de datos antes de la actualización para revertirla si surge algún problema. Los clústeres de Aurora admiten actualizaciones de versiones principales en el mismo lugar con una interrupción mínima.

Compruebe sus conocimientos sobre los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección ha aprendido que: RDS admite seis motores (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server y Aurora); las clases de instancia se corresponden con perfiles de carga de trabajo (db.t para desarrollo y pruebas, db.m para uso general y db.r para cargas con mucha memoria); y Aurora ofrece un rendimiento superior y escalado automático del almacenamiento en comparación con los motores de la comunidad. A continuación exploraremos las implementaciones Multi-AZ y las copias de seguridad automatizadas para lograr alta disponibilidad.