Parámetros del servidor en Azure Database for MySQL: servidor flexible
SE APLICA A:
Azure Database for MySQL: Servidor flexible
En este artículo se incluyen consideraciones e instrucciones para configurar parámetros del servidor en el servidor flexible de Azure Database for MySQL.
Nota:
Este artículo contiene referencias al término esclavo, un término que Microsoft ya no usa. Cuando se elimine el término del software, se eliminará también de este artículo.
¿Qué son las variables de servidor?
El motor MySQL proporciona muchas variables o parámetros de servidor diferentes que se pueden usar para configurar y ajustar el comportamiento del motor. Algunos parámetros se pueden establecer de forma dinámica en tiempo de ejecución, mientras que otros son "estáticos", requiriendo un reinicio del servidor para su aplicación.
El servidor flexible de Azure Database for MySQL expone la capacidad de cambio del valor de diversos parámetros del servidor MySQL mediante Azure Portal y la CLI de Azure para satisfacer las necesidades de la carga de trabajo.
Parámetros configurables del servidor
Puede administrar la configuración del servidor flexible de Azure Database for MySQL con los parámetros de servidor. Los parámetros de servidor se configuran con los valores predeterminados y recomendados al crear el servidor. La hoja de parámetros del servidor en Azure Portal muestra los parámetros del servidor modificables y no modificables. Los parámetros de servidor no modificables están atenuados.
La lista de parámetros del servidor admitidos crece constantemente. Use la pestaña Parámetros del servidor de Azure Portal para ver la lista completa y configurar valores de los parámetros del servidor.
Consulta las siguientes secciones para más información sobre los límites de varios parámetros del servidor actualizados habitualmente. Los límites vienen determinados por el nivel de proceso y el tamaño (núcleos virtuales) del servidor.
Nota
- Si modificas un parámetro de servidor estático mediante el portal, debes reiniciar el servidor para que los cambios surtan efecto. En caso de que use scripts de automatización (mediante herramientas como plantillas de ARM, Terraform, la CLI de Azure, etc.), el script debe tener un aprovisionamiento para reiniciar el servicio a fin de que la configuración surta efecto incluso si va a cambiar las configuraciones como parte de la experiencia de creación.
- Si quieres modificar un parámetro de servidor no modificable para su entorno, abre un elemento de UserVoice o vota si ya existen comentarios que puedan ayudarnos a priorizar.
lower_case_table_names
En la versión 5.7 de MySQL, el valor predeterminado es 1 en el servidor flexible de Azure Database for MySQL. Es importante tener en cuenta que, aunque es posible cambiar el valor admitido a 2, no se permite revertir de 2 a 1. Póngase en contacto con nuestro equipo de soporte técnico para obtener ayuda para cambiar el valor predeterminado. Para la versión 8.0+ de MySQL lower_case_table_names solo se puede configurar al inicializar el servidor. Más información. Se prohíbe cambiar la configuración de lower_case_table_names después de inicializar el servidor. En la versión 8.0 de MySQL, el valor predeterminado es 1 en el servidor flexible de Azure Database for MySQL. El valor admitido para la versión 8.0 de MySQL es 1 y 2 en el servidor flexible de Azure Database for MySQL. Póngase en contacto con nuestro equipo de soporte técnico para obtener ayuda para cambiar el valor predeterminado durante la creación del servidor.
innodb_tmpdir
El parámetro innodb_tmpdir del servidor flexible de Azure Database for MySQL se usa para definir el directorio para los archivos de ordenación temporales creados durante las operaciones ALTER TABLE en línea que se vuelven a generar. El valor predeterminado de innodb_tmpdir es /mnt/temp. Esta ubicación corresponde a la SSD de almacenamiento temporal, disponible en GiB con cada tamaño de proceso del servidor. Esta ubicación es ideal para las operaciones que no requieren una gran cantidad de espacio.
Si se necesita más espacio, puede establecer innodb_tmpdir en /app/work/tmpdir. Esto usa el almacenamiento, la capacidad disponible en el servidor flexible de Azure Database for MySQL. Esto puede ser útil para las operaciones más grandes que requieren un almacenamiento más temporal.
Es importante tener en cuenta que el uso de /app/work/tmpdir resulta en un rendimiento más lento en comparación con el almacenamiento temporal predeterminado (SSD)/mnt/temp. Se debe elegir en función de los requisitos específicos de las operaciones.
La información proporcionada para innodb_tmpdir es aplicable a los parámetros innodb_temp_tablespaces_dir, tmpdir y slave_load_tmpdir donde el valor predeterminado /mnt/temp es común, y el directorio alternativo /app/work/tmpdir está disponible para configurar un mayor almacenamiento temporal, con un equilibrio en el rendimiento basado en requisitos operativos específicos.
log_bin_trust_function_creators
En el servidor flexible de Azure Database for MySQL, siempre están habilitados los registros binarios (p. ej., log_bin está establecido en ON). log_bin_trust_function_creators se establece en ON de manera predeterminada en servidores flexibles.
El formato de registro binario siempre es ROW y todas las conexiones al servidor ALWAYS usan un registro binario basado en filas. Con el registro binario basado en filas, los problemas de seguridad no existen y el registro binario no puede romperse, por lo que puedes permitir que log_bin_trust_function_creators permanezca ON de forma segura.
Si [log_bin_trust_function_creators] está establecido en OFF cuando intente crear desencadenadores podría obtener errores similares a No tiene el privilegio SUPER y el registro binario está habilitado (se recomienda usar la variable menos segura log_bin_trust_function_creators).
innodb_buffer_pool_size
Consulte la documentación de MySQL para más información acerca de este parámetro.
| Plan de tarifa | Núcleos virtuales | Tamaño de memoria (GiB) | Valor predeterminado (bytes) | Valor mínimo (bytes) | Valor máximo (bytes) |
|---|---|---|---|---|---|
| Ampliable (B1s) | 1 | 1 | 134217728 | 33554432 | 134217728 |
| Ampliable (B1ms) | 1 | 2 | 536870912 | 134217728 | 536870912 |
| Flexible | 2 | 4 | 2147483648 | 134217728 | 2147483648 |
| Uso general | 2 | 8 | 5368709120 | 134217728 | 5368709120 |
| De uso general | 4 | 16 | 12884901888 | 134217728 | 12884901888 |
| De uso general | 8 | 32 | 25769803776 | 134217728 | 25769803776 |
| De uso general | 16 | 64 | 51539607552 | 134217728 | 51539607552 |
| De uso general | 32 | 128 | 103079215104 | 134217728 | 103079215104 |
| De uso general | 48 | 192 | 154618822656 | 134217728 | 154618822656 |
| De uso general | 64 | 256 | 206158430208 | 134217728 | 206158430208 |
| Crítico para la empresa | 2 | 16 | 12884901888 | 134217728 | 12884901888 |
| Crítico para la empresa | 4 | 32 | 25769803776 | 134217728 | 25769803776 |
| Crítico para la empresa | 8 | 64 | 51539607552 | 134217728 | 51539607552 |
| Crítico para la empresa | 16 | 128 | 103079215104 | 134217728 | 103079215104 |
| Crítico para la empresa | 32 | 256 | 206158430208 | 134217728 | 206158430208 |
| Crítico para la empresa | 48 | 384 | 309237645312 | 134217728 | 309237645312 |
| Crítico para la empresa | 64 | 504 | 405874409472 | 134217728 | 405874409472 |
innodb_file_per_table
MySQL almacena la tabla InnoDB en distintos espacios de tabla en función de la configuración proporcionada durante la creación de la tabla. El espacio de tablas del sistema es el área de almacenamiento del diccionario de datos de InnoDB. Un espacio de tabla de archivo por tabla contiene datos e índices para una sola tabla de InnoDB y se almacena en el sistema de archivos, en su propio archivo de datos. Este comportamiento se controla mediante el parámetro de servidor innodb_file_per_table. Si innodb_file_per_table se establece en OFF, InnoDB crea tablas en el espacio de tablas del sistema. De lo contrario, InnoDB crea tablas en espacios de tabla de archivo por tabla.
El servidor flexible de Azure Database for MySQL admite 4 TB como máximo en un solo archivo de datos. Si el tamaño de la base de datos es superior a 4 TB, debería crear la tabla en el espacio de tabla innodb_file_per_table. Si tiene una sola tabla de tamaño superior a 4 TB, debería usar la tabla de particiones.
innodb_log_file_size
innodb_log_file_size es el tamaño en bytes de cada archivo de registro de un grupo de registros. El tamaño combinado de los archivos de registro (innodb_log_file_size * innodb_log_files_in_group) no puede superar un valor máximo ligeramente inferior a 512 GB). Un tamaño de archivo de registro más grande es mejor para el rendimiento, pero tiene el inconveniente de que el tiempo de recuperación después de un bloqueo es alto. Debe equilibrar el tiempo de recuperación en el caso poco frecuente de una recuperación de bloqueo frente a maximizar el rendimiento durante las operaciones máximas. También pueden dar lugar a tiempos de reinicio más largos. Puede configurar innodb_log_size en cualquiera de estos valores: 256 MB, 512 MB, 1 GB o 2 GB para el servidor flexible de Azure Database for MySQL. El parámetro es estático y requiere un reinicio.
Nota
Si ha cambiado el parámetro innodb_log_file_size del valor predeterminado, compruebe si el valor de "mostrar el estado global como "innodb_buffer_pool_pages_dirty"" permanece en 0 durante 30 segundos para evitar el retraso del reinicio.
max_connections
El valor de max_connection viene determinado por el tamaño de la memoria del servidor.
| Plan de tarifa | Núcleos virtuales | Tamaño de memoria (GiB) | Valor predeterminado | Valor mínimo | Valor máximo |
|---|---|---|---|---|---|
| Ampliable (B1s) | 1 | 1 | 85 | 10 | 171 |
| Ampliable (B1ms) | 1 | 2 | 171 | 10 | 341 |
| Flexible | 2 | 4 | 341 | 10 | 683 |
| De uso general | 2 | 8 | 683 | 10 | 1365 |
| De uso general | 4 | 16 | 1365 | 10 | 2731 |
| De uso general | 8 | 32 | 2731 | 10 | 5461 |
| De uso general | 16 | 64 | 5461 | 10 | 10923 |
| De uso general | 32 | 128 | 10923 | 10 | 21845 |
| De uso general | 48 | 192 | 16384 | 10 | 32 768 |
| De uso general | 64 | 256 | 21845 | 10 | 43691 |
| Crítico para la empresa | 2 | 16 | 1365 | 10 | 2731 |
| Crítico para la empresa | 4 | 32 | 2731 | 10 | 5461 |
| Crítico para la empresa | 8 | 64 | 5461 | 10 | 10923 |
| Crítico para la empresa | 16 | 128 | 10923 | 10 | 21845 |
| Crítico para la empresa | 32 | 256 | 21845 | 10 | 43691 |
| Crítico para la empresa | 48 | 384 | 32 768 | 10 | 65536 |
| Crítico para la empresa | 64 | 504 | 43008 | 10 | 86016 |
Si las conexiones superan el límite, puede que reciba el error siguiente:
ERROR 1040 (08004): Demasiadas conexiones
Importante
Para obtener la mejor experiencia posible, se recomienda usar un agrupador de conexiones, como ProxySQL, para administrar las conexiones de forma eficaz.
La creación de conexiones de cliente a MySQL lleva tiempo y, una vez establecidas, estas conexiones ocupan recursos de bases de datos, incluso cuando están inactivas. La mayoría de las aplicaciones solicitan muchas conexiones de corta duración, y esto es lo que conforma esta situación. El resultado es que hay menos recursos disponibles para la carga de trabajo real, lo que baja el rendimiento. Un agrupador de conexiones que reduce las conexiones inactivas y reutiliza las conexiones existentes ayuda a evitar esto. Para más información sobre cómo configurar ProxySQL, consulte nuestra entrada de blog.
Nota
ProxySQL es una herramienta de la comunidad de código abierto. Es compatible con Microsoft dentro de lo posible. Para obtener soporte a la producción con instrucciones autoritativas, puede evaluar y ponerse en contacto con el servicio de soporte técnico de ProxySQL.
innodb_strict_mode
Si recibe un error similar a "Tamaño de la fila demasiado grande (> 8126)", puede desactivar el parámetro innodb_strict_mode. El parámetro del servidor innodb_strict_mode no se puede modificar globalmente en el nivel del servidor porque si el tamaño de los datos de la fila es superior a 8k, los datos se truncan sin errores, lo que puede provocar una posible pérdida de datos. Se recomienda modificar el esquema para ajustarlo al límite de tamaño de página.
Este parámetro se puede establecer en un nivel de sesión mediante init_connect. Para establecer innodb_strict_mode en el nivel de sesión, consulte cómo ajustar un parámetro que no aparece en la lista.
Nota
Si tiene un servidor de réplica de lectura, al establecer innodb_strict_mode como desactivado en el nivel de sesión de un servidor de origen, se interrumpirá la replicación. Se recomienda mantener el parámetro establecido en Activado si tiene réplicas de lectura.
time_zone
Tras la implementación inicial, una instancia del servidor flexible de Azure Database for MySQL incluye tablas del sistema para la información de zona horaria, pero estas tablas no se rellenan. Las tablas de la zona horaria se pueden rellenar mediante una llamada al procedimiento almacenado mysql.az_load_timezone desde una herramienta como la línea de comandos de MySQL o MySQL Workbench. Vea los artículos de Azure Portal o de la CLI de Azure sobre cómo llamar al procedimiento almacenado y establecer las zonas horarias globales o de nivel de sesión.
binlog_expire_logs_seconds
En el servidor flexible de Azure Database for MySQL, este parámetro especifica el número de segundos que el servicio espera antes de purgar el archivo de registro binario.
El registro binario contiene "eventos" que describen los cambios de la base de datos, como las operaciones de creación de tablas o los cambios en los datos de la tabla. También contiene eventos para instrucciones que puedan haber realizado cambios. El registro binario se usa con dos finalidades principalmente: las operaciones de replicación y de recuperación de datos. Normalmente, los registros binarios se purgan en cuanto el identificador queda libre del servicio, de la copia de seguridad o del conjunto de réplicas. Si hay varias réplicas, los registros binarios esperan a que la réplica más lenta lea los cambios antes de que se elimine. Si quieres conservar los registros binarios durante más tiempo, puedes configurar el parámetro binlog_expire_logs_seconds. Si binlog_expire_logs_seconds se establece en 0, que es el valor predeterminado, se purga tan pronto como se libera el identificador del registro binario. Si binlog_expire_logs_seconds > 0, entonces esperaría hasta los segundos configurados antes de purgar. En el servidor flexible de Azure Database for MySQL, las características administradas, como la copia de seguridad y la purga de réplicas de lectura de archivos binarios, se controlan internamente. Si se replican los datos fuera del servidor flexible de Azure Database for MySQL, este parámetro debe establecerse como primario para evitar la purga de registros binarios antes de que la réplica lea los cambios del elemento primario. Si estableces binlog_expire_logs_seconds en un valor más alto, los registros binarios no se eliminarán lo suficientemente pronto y pueden provocar un aumento en la facturación del almacenamiento.
event_scheduler
En el servidor flexible de Azure Database for MySQL, el parámetro de servidor event_schedule administra la creación, la programación y la ejecución de eventos, es decir, las tareas que se ejecutan según una programación y se ejecutan mediante un subproceso especial del programador de eventos. Cuando el parámetro event_scheduler se establece en ON, el subproceso del programador de eventos aparece como un proceso de demonio en la salida de MOSTRAR PROCESSLIST. Puedes crear y programar eventos mediante la siguiente sintaxis SQL:
CREATE EVENT <event name>
ON SCHEDULE EVERY _ MINUTE / HOUR / DAY
STARTS TIMESTAMP / CURRENT_TIMESTAMP
ENDS TIMESTAMP / CURRENT_TIMESTAMP + INTERVAL 1 MINUTE / HOUR / DAY
COMMENT ‘<comment>’
DO
<your statement>;
Nota
Para obtener más información sobre cómo crear un evento, consulta la documentación de Event Scheduler de MySQL aquí:
Configuración del parámetro de servidor event_scheduler
En el escenario siguiente se muestra una manera de usar el parámetro event_scheduler en el servidor flexible de Azure Database for MySQL. Para demostrar el escenario, considera el ejemplo siguiente, una tabla sencilla:
mysql> describe tab1;
+-----------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-----------+-------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| CreatedAt | timestamp | YES | | NULL | |
| CreatedBy | varchar(16) | YES | | NULL | |
+-----------+-------------+------+-----+---------+----------------+
3 rows in set (0.23 sec)
Para configurar el parámetro de servidor event_scheduler en el servidor flexible de Azure Database for MySQL, realice los pasos siguientes:
En Azure Portal, vaya a la instancia de servidor flexible de Azure Database for MySQL y, a continuación, en Configuración, seleccione Parámetros del servidor.
En la hoja Parámetros del servidor, busca
event_scheduleren la lista desplegable VALUE, selecciona ON y, a continuación, selecciona Guardar.Nota
El cambio de configuración de parámetros del servidor dinámico se implementará sin reiniciar.
A continuación, para crear un evento, conéctese a la instancia del servidor flexible de Azure Database for MySQL y ejecute el siguiente comando SQL:
CREATE EVENT test_event_01 ON SCHEDULE EVERY 1 MINUTE STARTS CURRENT_TIMESTAMP ENDS CURRENT_TIMESTAMP + INTERVAL 1 HOUR COMMENT ‘Inserting record into the table tab1 with current timestamp’ DO INSERT INTO tab1(id,createdAt,createdBy) VALUES('',NOW(),CURRENT_USER());Para ver los detalles de Event Scheduler, ejecute la siguiente instrucción SQL:
SHOW EVENTS;Se mostrará lo siguiente:
mysql> show events; +-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+ | Db | Name | Definer | Time zone | Type | Execute at | Interval value | Interval field | Starts | Ends | Status | Originator | character_set_client | collation_connection | Database Collation | +-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+ | db1 | test_event_01 | azureuser@% | SYSTEM | RECURRING | NULL | 1 | MINUTE | 2023-04-05 14:47:04 | 2023-04-05 15:47:04 | ENABLED | 3221153808 | latin1 | latin1_swedish_ci | latin1_swedish_ci | +-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+ 1 row in set (0.23 sec)Después de unos minutos, consulte las filas de la tabla para empezar a ver las filas insertadas cada minuto según el parámetro
event_schedulerque configuró:mysql> select * from tab1; +----+---------------------+-------------+ | id | CreatedAt | CreatedBy | +----+---------------------+-------------+ | 1 | 2023-04-05 14:47:04 | azureuser@% | | 2 | 2023-04-05 14:48:04 | azureuser@% | | 3 | 2023-04-05 14:49:04 | azureuser@% | | 4 | 2023-04-05 14:50:04 | azureuser@% | +----+---------------------+-------------+ 4 rows in set (0.23 sec)Después de una hora, ejecute una instrucción Select en la tabla para ver el resultado completo de los valores insertados en la tabla cada minuto durante una hora, ya que
event_schedulerse configura en nuestro caso.mysql> select * from tab1; +----+---------------------+-------------+ | id | CreatedAt | CreatedBy | +----+---------------------+-------------+ | 1 | 2023-04-05 14:47:04 | azureuser@% | | 2 | 2023-04-05 14:48:04 | azureuser@% | | 3 | 2023-04-05 14:49:04 | azureuser@% | | 4 | 2023-04-05 14:50:04 | azureuser@% | | 5 | 2023-04-05 14:51:04 | azureuser@% | | 6 | 2023-04-05 14:52:04 | azureuser@% | ..< 50 lines trimmed to compact output >.. | 56 | 2023-04-05 15:42:04 | azureuser@% | | 57 | 2023-04-05 15:43:04 | azureuser@% | | 58 | 2023-04-05 15:44:04 | azureuser@% | | 59 | 2023-04-05 15:45:04 | azureuser@% | | 60 | 2023-04-05 15:46:04 | azureuser@% | | 61 | 2023-04-05 15:47:04 | azureuser@% | +----+---------------------+-------------+ 61 rows in set (0.23 sec)
Otros escenarios
Puede configurar un evento en función de los requisitos de su escenario específico. A continuación se muestran algunos ejemplos similares de programación de instrucciones SQL para ejecutarse a intervalos de tiempo diferentes.
Ejecución de una instrucción SQL ahora y repetición una vez al día sin fin
CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 DAY
STARTS (TIMESTAMP(CURRENT_DATE) + INTERVAL 1 DAY + INTERVAL 1 HOUR)
COMMENT 'Comment'
DO
<your statement>;
Ejecución de una instrucción SQL cada hora sin fin
CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 HOUR
COMMENT 'Comment'
DO
<your statement>;
Ejecución de una instrucción SQL cada día sin fin
CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 DAY
STARTS str_to_date( date_format(now(), '%Y%m%d 0200'), '%Y%m%d %H%i' ) + INTERVAL 1 DAY
COMMENT 'Comment'
DO
<your statement>;
Limitaciones
Para los servidores con alta disponibilidad configurada, cuando se produce la conmutación por error, es posible que el parámetro del servidor event_scheduler se establezca en "OFF". Si esto ocurre, cuando se complete la conmutación por error, configura el parámetro para establecer el valor en "ON".
Parámetros del servidor no modificables
La hoja de parámetros del servidor en Azure Portal muestra los parámetros del servidor modificables y no modificables. Los parámetros del servidor no modificables están atenuados. Si deseas configurar un parámetro de servidor no modificable a nivel de sesión, consulta el artículo de Azure Portal o la CLI de Azure para configurar el parámetro en el nivel de conexión mediante init_connect.
Pasos siguientes
- Cómo configurar parámetros del servidor en Azure Portal
- Cómo configurar parámetros de servidor en la CLI de Azure