Desde hace unos meses Amazon Web Services viene avisando del fin del soporte de las versiones anteriores a la RDS MariaDB 10.3. Se convierte casi en una obligación realizar una actualización. Si te encuentras en esa situación, te explicamos a continuación cómo solventar algunos problemas de performance con los que puedes encontrarte.
Cabe destacar que, en este caso, vamos a actualizar una base de datos MariaDB versión 10.0.17. Después de observar la frecuencia con la que MariaDB y AWS actualizan su entorno, decidimos decantarnos por actualizar a MariaDB 10.4.8.
Aparentemente los cambios entre versiones únicamente afectan a un par de variables globales, las cuales no son stopper para realizar la actualización. Puedes consultar los cambios de variables aquí.
La actualización transcurre sin ningún imprevisto ni error. Pero en poco tiempo, empezamos a observar una degradación de la performance en la base de datos y un aumento significativo del consumo de CPU.
Debugando una de las consultas que está penalizando, realizando un EXPLAIN de la misma, nos encontramos diferencias entre versiones. Parece ser que, las estadísticas con las que el motor de la base de datos cuenta para optimizar las queries se ha visto afectado de algún modo por la migración.
Indagando en la casuística, y comparando variables de entorno, nos damos cuenta que el valor por defecto de las variables globales use_stat_tables y optimizer_user_condition_selectivity han cambiado:
El cambio en el optimizador se realiza en la versión 10.4 y esto implica un nuevo plan de ejecución, en función de la cardinalidad de los índices que se deben utilizar. En la documentación oficial podemos leer que el valor campo optimizer_use_condition_selectivity puede ser de 0 a 5.
En el caso que nos ocupa, nos fijamos en los valores 1 y 4, que son los que nos afectan directamente. En la documentación oficial encontramos el significado de estos valores:
Con el valor a 4:
“el optimizador hará uso de histogramas para calcular la selectividad de las condiciones de rango que no están respaldadas por ningún índice para calcular la cardinalidad de una combinación parcial. ”
En cambio con el valor a 1:
“se hará uso de la selectividad de las condiciones de rango respaldado por índice para calcular la cardinalidad de un JOIN parcial si se accede a la última tabla unida mediante un escaneo de tabla completo o un escaneo de índice.”
Como workaround decidimos setear la variable optimizer_use_condition_selectivity a 1, tal y como estaba en MariaDB 10.0.17.
Para modificar la variable en una RDS, debemos realizar los siguientes pasos:
01. Accedemos a la consola de AWS y seleccionamos Relational Database Service (RDS)
02. Seleccionamos la instancia, clicamos en Configuración y seleccionamos el Parameter Group que tenemos asignado en la instancia:
03. Una vez nos encontramos en la página principal de Parameter Group, buscamos el parámetro que nos ocupa:
04. Lo seleccionamos y clicamos en Editar parámetro e introducimos el valor deseado, en este caso 1, y guardamos:
IMPORTANTE: Una vez modificado el parámetro, la base de datos tiene que ser reiniciada para que los cambios se apliquen, de otro modo no se verán reflejados.
Con esto conseguimos que el orden en el que se efectua el plan de ejecución, vuelva a ser el mismo que siempre. También conseguimos que el tiempo de respuesta como la CPU de la base de datos se recupere.
Tal y como se indica más arriba, se trata de un workaround y se debe seguir indagando, tanto en cómo optimizar las consultas, como en analizar las variables más en detalle y modificarlas según nuestro entorno.