Procedimientos recomendados para compilar una aplicación con Azure Database for MySQL

  • Artículo

SE APLICA A: Azure Database for MySQL: servidor único Azure Database for MySQL: servidor flexible

Importante

El servidor único de Azure Database for MySQL está en la ruta de retirada. Se recomienda encarecidamente actualizar al servidor flexible de Azure Database for MySQL. Para más información sobre la migración al servidor flexible de Azure Database for MySQL, consulte ¿Qué ocurre con Azure Database for MySQL con servidor único?

Estos son algunos procedimientos recomendados que le ayudarán a compilar una aplicación preparada para la nube mediante Azure Database for MySQL. Estos procedimientos recomendados pueden reducir el tiempo de desarrollo de la aplicación.

Configuración de recursos de aplicación y de base de datos

Mantenga la aplicación y la base de datos en la misma región.

Al implementar la aplicación en Azure, asegúrese de que todas las dependencias están en la misma región. La propagación de instancias entre regiones o zonas de disponibilidad crea latencia de red, lo que puede afectar al rendimiento general de la aplicación.

Mantenimiento de la seguridad del servidor MySQL

Configure el servidor MySQL como seguro y no se pueda acceder a él de forma pública. Use cualquiera de estas opciones para proteger el servidor:

Por seguridad, siempre debe conectarse al servidor MySQL a través de SSL y configurar el servidor MySQL y la aplicación para que usen TLS 1.2. Vea Conectividad SSL/TLS.

Uso de redes avanzadas con AKS

Cuando las redes aceleradas están habilitadas en una máquina virtual, la latencia, la inestabilidad y el uso de CPU son menores en la máquina virtual. Para obtener más información, vea Procedimientos recomendados para Azure Kubernetes Service y Azure Database for MySQL.

Ajuste de los parámetros del servidor

En el caso de cargas de trabajo con muchas operaciones de lectura, el ajuste de los parámetros tmp_table_size y max_heap_table_size puede ayudar a optimizar el rendimiento. Para calcular los valores necesarios para estas variables, examine los valores de memoria total por conexión y la memoria base. La suma de los parámetros de memoria por conexión, excluido tmp_table_size, junto con la memoria base, da como resultado la memoria total del servidor.

Para calcular el mayor tamaño posible de tmp_table_size y max_heap_table_size, use la siguiente fórmula:

(total memory - (base memory + (sum of per-connection memory * # of connections)) / # of connections

Nota

La memoria total indica la cantidad total de memoria que el servidor tiene en los núcleos virtuales aprovisionados. Por ejemplo, en un servidor de Azure Database for MySQL con dos núcleos virtuales de uso general, la memoria total será 5 GB * 2. Puede encontrar más información sobre la memoria en cada nivel en la documentación del plan de tarifa.

La memoria base indica las variables de memoria, como query_cache_size y innodb_buffer_pool_size, que MySQL inicializará y asignará al inicio del servidor. La memoria por conexión, como sort_buffer_size y join_buffer_size, es la memoria que se asigna solo cuando una consulta la necesita.

Creación de usuarios no administradores

Cree usuarios que no sean administradores para cada una de las bases de datos. Normalmente, los nombres de usuario se identifican como nombres de base de datos.

Restablecimiento de la contraseña

Puede restablecer la contraseña del servidor MySQL mediante Azure Portal.

El restablecimiento de la contraseña del servidor de una base de datos de producción puede desactivar la aplicación. Una buena práctica es restablecer la contraseña de cualquier carga de trabajo de producción en horas de poca actividad para reducir los efectos en los usuarios de la aplicación.

Rendimiento y resistencia

Estas son algunas herramientas y prácticas que le ayudarán a depurar los problemas de rendimiento de su aplicación.

Habilitación de los registros de consultas lentas para identificar problemas de rendimiento

Puede habilitar los registros de consultas lentas y los registros de auditoría en el servidor. El análisis de consultas lentas puede ayudar a identificar cuellos de botella que afectan al rendimiento a fin de solucionar el problema.

Los registros de auditoría también están disponibles mediante los registros de Azure Diagnostics en los registros de Azure Monitor, Event Hubs y las cuentas de almacenamiento. Consulte Solución de problemas del rendimiento de las consultas.

Use agrupar conexiones

La administración de conexiones de base de datos puede tener un impacto significativo en el rendimiento de la aplicación en su conjunto. Para optimizar el rendimiento, debe reducir el número de veces que se establecen las conexiones y el tiempo para establecerlas en las rutas de acceso al código principal. Use Agrupación de conexiones para conectarse a Azure Database for MySQL, a fin de mejorar la resistencia y el rendimiento.

Puede usar el agrupador de conexiones ProxySQL para administrar de forma eficaz las conexiones. Con un agrupador de conexiones, puede reducir las conexiones inactivas y reutilizar las conexiones existentes, lo que ayuda a evitar problemas. Consulte Configuración de ProxySQL para más información.

Lógica de reintento para controlar errores transitorios

La aplicación podría experimentar errores transitorios en los que las conexiones a la base de datos se rechazan o se pierden de manera intermitente. En tales situaciones, el servidor se pone en funcionamiento al cabo de uno o dos reintentos en 5 o 10 segundos.

Una buena práctica es esperar 5 segundos antes del primer reintento. Después, aumente gradualmente la espera entre cada reintento, hasta 60 segundos. Para investigar el problema más a fondo, limite el número máximo de reintentos en cuyo momento la aplicación considera que se produjo un error en la operación. Consulte Solución de problemas de conexión para más información.

Habilitar la replicación de lectura para mitigar las conmutaciones por error

Se puede usar la Replicación de datos de entrada en los escenarios de conmutación por error. Cuando se usan réplicas de lectura, no se produce una conmutación por error automatizada entre servidores de origen y réplicas.

Observará un retraso entre el servidor de origen y la réplica, ya que la replicación es asincrónica. El retraso de red puede verse afectado por muchos factores, por ejemplo, el tamaño de la carga de trabajo que se ejecuta en el servidor de origen y la latencia entre los centros de datos. En la mayoría de los casos, el retraso de la réplica oscila entre unos segundos y unos pocos minutos.

Implementación de bases de datos

Configuración de una tarea de Azure Database for MySQL en la canalización de implementación de CI/CD

En ocasiones, es necesario implementar cambios en la base de datos. En tales casos, puede usar la integración continua (CI) y la entrega continua (CD) mediante Azure Pipelines y emplear una tarea para que el servidor MySQL actualice la base de datos mediante la ejecución de un script personalizado en ella.

Uso de un proceso eficaz para la implementación manual de bases de datos

Durante la implementación manual de bases de datos, siga estos pasos para minimizar el tiempo de inactividad o reducir el riesgo de implementaciones con errores:

  1. Cree una copia de una base de datos de producción en una nueva base de datos mediante mysqldump o MySQL Workbench.
  2. Actualice la nueva base de datos con los nuevos cambios de esquema o las actualizaciones necesarias de la base de datos.
  3. Ponga la base de datos de producción en estado de solo lectura. Sería mejor si no tuviera operaciones de escritura en la base de datos de producción hasta que se complete la implementación.
  4. Pruebe la aplicación con la base de datos recién actualizada del paso 1.
  5. Implemente los cambios de la aplicación y asegúrese de que la aplicación usa ahora la nueva base de datos con las actualizaciones más recientes.
  6. Mantenga la antigua base de datos de producción para poder revertir los cambios. Después, puede valorar eliminar la base de datos de producción antigua o exportarla en Azure Storage, si es necesario.

Nota

Si la aplicación es como una aplicación de comercio electrónico y no puede ponerla en estado de solo lectura, implemente los cambios directamente en la base de datos de producción después de realizar una copia de seguridad. Estos cambios deben realizarse durante las horas de poca actividad y poco tráfico a la aplicación, para que tengan el menor efecto posible, ya que algunos usuarios pueden experimentar solicitudes con error.

Asegúrese de que el código de aplicación también controla las solicitudes con error.

Uso de las métricas nativas de MySQL para ver si la carga de trabajo supera los tamaños de tablas temporales en memoria

Cuando hay cargas de trabajo con muchas operaciones de lectura, las consultas que se ejecutan en el servidor MySQL pueden superar los tamaños de tablas temporales en memoria. Una carga de trabajo de este tipo puede hacer que el servidor pase a escribir tablas temporales en el disco, lo que afecta al rendimiento de la aplicación. Para determinar si el servidor está escribiendo en el disco como resultado de superar el tamaño de la tabla temporal, examine las métricas siguientes:

show global status like 'created_tmp_disk_tables';
show global status like 'created_tmp_tables';

La métrica created_tmp_disk_tables indica el número de tablas que se crearon en el disco. Dada la carga de trabajo, la métrica created_tmp_table indica cuántas tablas temporales se deben crear en la memoria. Para determinar si una consulta específica usa tablas temporales, ejecute la instrucción EXPLAIN en la consulta. Los detalles de la columna extra indican Using temporary si la consulta se ejecuta con tablas temporales.

Para calcular el porcentaje de la carga de trabajo con consultas que desbordan los discos, use los valores de las métricas en la fórmula siguiente:

(created_tmp_disk_tables / (created_tmp_disk_tables + created_tmp_tables)) * 100

Idealmente, este porcentaje debe ser inferior al 25 %. Si el porcentaje es del 25 % o superior, se recomienda modificar dos parámetros de servidor, tmp_table_size y max_heap_table_size.

Consultas y esquema de base de datos

A continuación se ofrecen algunos consejos que conviene recordar al crear el esquema de la base de datos y las consultas.

Uso del tipo de datos correcto para las columnas de la tabla

El uso de los tipos de datos correctos en función del tipo de datos que quiere almacenar puede optimizar el almacenamiento y reducir los errores debidos a tipos de datos incorrectos.

Uso de índices

Para evitar consultas lentas, puede utilizar índices. Los índices pueden ayudar a buscar filas con columnas específicas rápidamente. Consulte Uso de índices en MySQL.

Uso de instrucciones EXPLAIN en las consultas SELECT

Use la instrucción EXPLAIN para obtener información detallada sobre lo que hace MySQL para ejecutar la consulta. Puede ayudarle a detectar cuellos de botella o problemas con ella. Vea Uso de EXPLAIN para solucionar problemas relacionados con el rendimiento de consultas.