Un clúster de producción de Aurora MySQL es un nodo de escritor único y es consultado intensamente para informes. El clúster sufre problemas intermitentes de rendimiento debido al alto uso de CPU y al alcanzar el número máximo de conexiones. Un administrador de SysOps necesita estabilizar el rendimiento. ¿Qué solución abordará este requisito?

Crear una Aurora Replica y dirigir las consultas de informes al endpoint de solo lectura es la solución más efectiva. Aurora Replicas comparten el mismo almacenamiento subyacente que la instancia de escritor, lo que permite escalar la capacidad de lectura sin afectar el rendimiento de escritura. Una política de Auto Scaling asegura que se añadan réplicas automáticamente cuando la CPU esté alta, estabilizando el rendimiento. Aprovisionar un segundo clúster de Aurora MySQL no es ideal porque duplicaría el almacenamiento y la complejidad de la gestión de datos. Implementar una función Lambda para caché o un clúster ElastiCache podría ayudar con algunas consultas, pero no abordaría directamente el problema de la alta utilización de CPU y el límite de conexiones en la base de datos de informes, especialmente para consultas complejas o datos que cambian con frecuencia.