Como ya hemos comentado en nuestro último post sobre las bases de datos relacionales, AWS Aurora es un servicio cloud de alto rendimiento, escalable, monitoreado y fácil de usar, completamente administrado, compatible con MySQL y PostgreSQL
A continuación te presentamos las mejoras de este servicio, las cuales permiten que la gestión de BBDD sea mucho más óptima y resiliente.
Si este post te ha parecido interesante, te invitamos a descargar nuestro Ebook gratuito «¿Cómo migrar a Amazon Web Services?»
Mejoras de Amazon Aurora V1 a V2
Entre las mejoras constantes que AWS realiza en sus servicio, introdujo una nueva modalidad de Amazon Aurora con diferentes mejoras y diferencias dependiendo del caso de uso, Aurora Serverless V2 es un modo sin servidor que permite escalar a cientos de miles de transacciones en una fracción de segundo 
.
Además, admite una gran modalidad de trabajos, desde entornos de prueba o aplicaciones con cargas de trabajo poco frecuentes hasta aplicaciones que necesitan una alta escalabilidad y disponibilidad y es compatible con las otras características de Aurora.
1. Escalabilidad
Aurora Serverless V1: escala de forma automática, pero no lo puede hacer mientras haya conexiones en la base de datos para escalar, hay que esperar hasta que no haya transacciones en curso o configurar la base de datos para que se escale independientemente.
Aurora Serverless V2: En cambio, la versión 2 ofrece mejoras en escalabilidad, las instancias escalan automáticamente en milisegundos en función de la carga de la aplicación, ya sea hacia arriba o hacia abajo.
2. El failover y las réplicas de lectura
Aurora V1: Un clúster de Aurora Serverless V1 funciona como una única instancia de lectura/escritura sin réplicas de lectura. En caso de fallos, se creará un nuevo maestro, pero durante este tiempo no tendrá una base de datos.
Aurora V2: Un clúster de Aurora Serverless tienen conmutación por error completa y funciones de réplica de lectura de clústeres de Aurora aprovisionados regulares. Si el maestro falla, una de las réplicas de lectura actúa como un repuesto dinámico y la interrupción de la aplicación es mínima.
3. Clústeres
Los clústeres de Aurora V1 están completamente separados de las bases de datos aprovisionados normales y que no se pueden mezclar de forma nativa.
Por su parte, Aurora V2 permite usar una combinación de instancias de bases de datos aprovisionadas e instancias de bases de datos sin servidor en el mismo clúster, lo que le permite generar capacidad de ráfaga en sus clústeres de bases de datos tradicionales.
4. API de datos
Con Serverless V1 teníamos una “API de datos” que exponía la base de datos sin servidor a través de un punto final HTTP simple y se otorgaba acceso al punto final con permisos de IAM.
Sin embargo, Serverless V2 no tiene API de datos, por lo que es más difícil de usar con funciones Lambda.
5. Escalado cero
Aurora V1 puede escalar hasta 0 ACU y escalar de forma automática cuando se realizan solicitudes.
Las instancias de Aurora V2 no permiten escalar hasta 0 sino hasta 0’5 ACU y solamente escala hasta 256 GB de RAM y no 768 RAM.
6. Multi A-Z
Una de las limitantes que los clientes encontraban con Aurora V1 era la no disponibilidad de MultiA-Z. Para ello se han integrado en la versión 2 de Aurora, clústeres Muli-AZ que pueden distribuir las instancias de base de datos de un clúster entre varias zonas de disponibilidad. La configuración de un clúster Multi-AZ ayuda a garantizar la continuidad del negocio.
En conclusión, Aurora V1 es una opción recomendada para cargas de trabajo poco frecuentes, intermitentes o impredecibles, como aplicaciones de poco uso, Aurora V2 está más enfocada a cargas de trabajo de base de datos, desde desarrollos y entornos de pruebas, hasta aquellas aplicaciones empresariales críticas más exigentes.
Desde apser contamos con expertos para ayudarte con tu proceso de migración hacia la nube a través de un road map personalizado. Contacta con nosotros, estaremos encantados de conocer tu proyecto.
