Migración de MySQL en el entorno local a Azure Database for MySQL: líneas base de rendimiento
El establecimiento de líneas base de rendimiento es fundamental para migrar bases de datos MySQL desde entornos locales a Azure Database for MySQL. En este artículo se profundiza en la importancia de las líneas base de rendimiento, lo que proporciona una guía detallada sobre cómo medir y analizar el rendimiento actual de la base de datos. Al comprender las métricas de rendimiento existentes, puede establecer expectativas realistas e identificar áreas para mejorar durante el proceso de migración. Esta guía le proporciona conocimientos para crear líneas base de rendimiento precisas, lo que garantiza que las bases de datos migradas cumplan o superen sus niveles de rendimiento actuales en el entorno de Azure. Tanto si tiene como objetivo optimizar el rendimiento de las consultas, mejorar la escalabilidad o garantizar una experiencia de usuario coherente, en este artículo se proporcionan las conclusiones necesarias para lograr los objetivos de rendimiento.
Requisitos previos
Migración de datos de un entorno local de MySQL a Azure Database for MySQL: Test Plans
Información general
El conocimiento de la carga de trabajo de MySQL existente es una de las mejores inversiones que se pueden realizar para garantizar una migración correcta. Un rendimiento excelente del sistema depende del hardware adecuado y de un buen diseño de las aplicaciones. A los elementos como CPU, memoria, disco y redes se les debe ajustar el tamaño y hay que configurarlos correctamente para la carga prevista. El hardware y la configuración forman parte de la ecuación de rendimiento del sistema. El desarrollador debe conocer la carga de consultas de la base de datos y las consultas más caras que se van a ejecutar. Centrarse en las consultas más costosas puede afectar considerablemente a las métricas de rendimiento generales.
La creación de una base de referencia de rendimiento de consultas es fundamental para un proyecto de migración. La base de referencia de rendimiento se puede usar para comprobar la configuración de la zona de aterrizaje de Azure para las cargas de trabajo de datos migradas. La mayoría de los sistemas se ejecutan de manera ininterrumpida y tienen horas de carga máxima diferentes. Es importante capturar las cargas de trabajo máximas para la base de referencia. Las métricas se capturan varias veces. Más adelante en el documento, se analizarán los parámetros del servidor de origen y cómo estos son fundamentales para tener una perspectiva general de la base de referencia de rendimiento. Los parámetros del servidor no deben pasarse por alto durante un proyecto de migración.
Herramientas
A continuación se muestran las herramientas que se usan para recopilar métricas del servidor e información de la carga de trabajo de la base de datos. Use las métricas capturadas para determinar el nivel de servicio adecuado de Azure Database for MySQL y las opciones de escalado asociadas.
MySQL Enterprise Telemetry: esta herramienta de pago, en versión empresarial, puede proporcionar una lista ordenada de las consultas más caras, las métricas del servidor, la E/S de archivos e información sobre la topología
Percona Monitoring and Management (PMM): una solución avanzada de supervisión de bases de datos de código abierto. Ayuda a reducir la complejidad, optimizar el rendimiento y mejorar la seguridad de los entornos de base de datos críticos para la empresa, independientemente de la ubicación implementada.
Parámetros del servidor
Es posible que las configuraciones predeterminadas del servidor MySQL no admitan adecuadamente una carga de trabajo. Hay una gran cantidad de parámetros de servidor en MySQL, pero en la mayoría de los casos el equipo de migración debe centrarse solo en unos pocos. Los parámetros siguientes se deben evaluar en los entornos de origen y de destino. Las configuraciones incorrectas pueden afectar a la velocidad de la migración. Volveremos a repasar estos parámetros cuando se ejecuten los pasos de migración.
innodb_buffer_pool_size: un valor grande garantiza que los recursos en memoria se usen primero antes de usar la E/S de disco. Los valores típicos oscilan entre el 80 % y el 90 % de la memoria disponible. Por ejemplo, un sistema con 8 GB de memoria debe asignar entre 5 y 6 GB para el tamaño del grupo.
innodb_log_file_size: los registros de la fase de puesta al día garantizan escrituras rápidas y duraderas. Esta copia de seguridad transaccional es útil durante un bloqueo del sistema. Comenzar con innodb_log_file_size = 512M (dando 1 GB de registros de fase de puesta al día) debería dar suficiente espacio para escrituras. Las aplicaciones de escritura intensiva que usan MySQL 5.6 o superior deben comenzar con innodb_log_file_size = 4G.
max_connections: este parámetro puede ayudar a mitigar el error
Too many connections. El valor predeterminado es de 151 conexiones. Se prefiere usar un grupo de conexiones en el nivel de aplicación, pero es posible que también sea necesario aumentar la configuración de conexión del servidor.innodb_file_per_table: este valor le indica a InnoDB si debe almacenar datos e índices en el espacio de tablas compartido o en un archivo separate.ibd para cada tabla. Tener un archivo por tabla permite que el servidor recupere espacio cuando se descarten, trunquen o se vuelvan a crear las tablas. Las bases de datos que contienen muchas tablas no deben usar la tabla por configuración de archivo. A partir de MySQL 5.6, el valor predeterminado es ON. Las versiones anteriores de la base de datos deben establecer la configuración en ON antes de cargar los datos. Esta configuración solo afecta a las tablas recién creadas.
innodb_flush_log_at_trx_commit: el valor predeterminado de uno significa que InnoDB es totalmente compatible con ACID. Esta configuración de transacción de menor riesgo puede experimentar una sobrecarga significativa en los sistemas con discos lentos porque se necesitan sincronizaciones adicionales para vaciar cada cambio en los registros de la fase de puesta al día. Establecer el parámetro en 2 es un poco menos confiable porque las transacciones confirmadas se vaciarán en los registros de la fase de puesta al día solo una vez por segundo. El riesgo puede ser aceptable en algunas situaciones concretas y resulta un buen valor para una réplica. Un valor de 0 permite obtener un mejor rendimiento del sistema, pero es más probable que el servidor de bases de datos pierda algunos datos durante un error. En la línea inferior, se usa el valor 0 solo para una réplica.
innodb_flush_method: esta configuración controla cómo se vacían los datos y registros en el disco. Use
O_DIRECTcuando esté en presencia de un controlador RAID de hardware con una memoria caché de escritura diferida con protección de batería. Usefdatasync(valor predeterminado) para otros escenarios.innodb_log_buffer_size: esta configuración es el tamaño del búfer para las transacciones que aún no se han confirmado. El valor predeterminado (1 MB) es aceptable. Las transacciones con campos de blob o texto grandes pueden llenar el búfer rápidamente y desencadenar una carga de E/S adicional. Mire la variable de estado
Innodb_log_waitsy, si no es 0, aumenteinnodb_log_buffer_size.query_cache_size: la caché de consulta es un cuello de botella conocido que se puede observar durante una etapa de simultaneidad moderada. El valor inicial debe establecerse en 0 para deshabilitar la memoria caché, por ejemplo, query_cache_size = 0. Este es el valor predeterminado en MySQL 5.6 y versiones posteriores.
log_bin: esta configuración habilita el registro binario. La habilitación del registro binario es obligatoria si el servidor va a actuar como maestro de replicación.
server_id: este valor es un valor único para los servidores de identidad de las topologías de replicación.
expire_logs_days: este valor controla cuántos días se purgarán automáticamente los registros binarios.
skip_name_resolve: usuario que va a realizar la resolución del nombre de host del cliente. Si el DNS es lento, la conexión es lenta. Al deshabilitar la resolución de nombres, las instrucciones GRANT solo deben usar direcciones IP. Cualquier instrucción GRANT anterior tendría que rehacerse para usar la dirección IP.
Ejecute el siguiente comando para exportar los parámetros del servidor a un archivo para su revisión. Con un análisis sencillo, la salida puede volver a aplicar los mismos parámetros de servidor después de la migración, si procede, al servidor de Azure Database for MySQL. Consulte Configuración de parámetros del servidor en Azure Database for MySQL mediante Azure Portal
mysql -u root -p -A -e "SHOW GLOBAL VARIABLES;" > settings.txt
Los parámetros de servidor instalados predeterminados de MySQL 5.5.60 se pueden encontrar en el apéndice.
Antes de comenzar la migración, exporte los valores de configuración de MySQL de origen. Compare esos valores con la configuración de la instancia de la zona de aterrizaje de Azure después de la migración. Si se ha modificado algún valor predeterminado en la instancia de la zona de aterrizaje de Azure de destino, asegúrese de que se establecen de nuevo después de la migración. Además, el usuario de migración debe comprobar que los parámetros del servidor se pueden establecer antes de la migración.
Para obtener una lista de parámetros de servidor que no se pueden configurar, consulte Parámetros no configurables del servidor.
Entrada y salida
Los parámetros de servidor MySQL de origen y destino deben modificarse para cada herramienta de migración de datos y ruta de acceso correspondientes para admitir la salida y la entrada más rápidas posibles. En función de la herramienta, los parámetros podrían ser diferentes. Por ejemplo, una herramienta que realiza una migración en paralelo puede necesitar más conexiones entre el origen y el destino en comparación con una herramienta sencilla de subprocesos.
Revise los parámetros de tiempo de espera que puedan verse afectados por los conjuntos de datos. Entre ellas se incluyen las siguientes:
Además, revise los parámetros que afectan a los valores máximos:
Nota
Un error habitual en la migración es MySQL server has gone away. Los parámetros que se mencionan aquí son los típicos responsables de la resolución de este error.
Escenario de WWI
WWI ha revisado la carga de trabajo de la base de datos Conference y ha determinado que tenía una carga pequeña. Aunque un servidor de nivel básico funcionaría para ellos, no querían realizar el trabajo más adelante de migrar a otro nivel de servicio. El servidor que se implemente hospedará finalmente las demás cargas de trabajo de datos de MySQL y, por tanto, han elegido el nivel General Performance.
Al revisar la base de datos MySQL, he encontrado que el servidor MySQL 5.5 se ejecuta con los parámetros de servidor predeterminados establecidos durante la instalación inicial.