Parámetros del servidor en Azure Database for MySQL: servidor flexible

Artículo
12/19/2024

En este artículo, se incluyen consideraciones e instrucciones para configurar parámetros del servidor en Azure DB for MySQL: servidor flexible.

Nota:

Este artículo contiene referencias al término estado subordinado, que Microsoft ya no usa. Cuando se elimine el término del software, se eliminará también de este artículo.

¿Cuáles son los parámetros del servidor?

El motor MySQL proporciona muchos parámetros de servidor (también denominados variables) que puede usar para configurar y optimizar el comportamiento del motor. Algunos parámetros se pueden establecer dinámicamente durante el runtime. Otros son estáticos y requieren un reinicio del servidor después de establecerlos.

En Azure Database for MySQL: servidor flexible, puede cambiar el valor de varios parámetros del servidor MySQL mediante Configuración de parámetros de servidor en Azure Database for MySQL: servidor flexible mediante Azure Portal o Configuración de parámetros de servidor en Azure Database for MySQL: servidor flexible mediante la CLI de Azure para ajustarlos a las necesidades de la carga de trabajo.

Parámetros configurables del servidor

Puede administrar la configuración de Azure Database for MySQL: servidor flexible 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 modificables y no modificables. Los parámetros de servidor no modificables no están disponibles.

La lista de parámetros del servidor admitidos crece constantemente. Puede usar Azure Portal para ver periódicamente la lista completa de parámetros de servidor y configurar los valores.

Si modificas un parámetro de servidor estático mediante el portal, debe reiniciar el servidor para que los cambios surtan efecto. Si usa scripts de automatización (a través de herramientas como plantillas de Azure Resource Manager, Terraform o la CLI de Azure), el script debe tener un aprovisionamiento para reiniciar el servicio para que la configuración surta efecto, aunque cambie la configuración como parte de la experiencia de creación.

Si desea modificar un parámetro de servidor no modificable para su entorno, publique una idea a través de comentarios de la comunidad o vote si los comentarios ya existen (lo que puede ayudarnos a priorizar).

En las secciones siguientes se describen los límites de los parámetros de servidor actualizados habitualmente. El nivel de proceso y el tamaño (núcleos virtuales) del servidor determinan los límites.

lower_case_table_names

En la versión 5.7 de MySQL, el valor predeterminado de lower_case_table_names es 1 en el servidor flexible de Azure Database for MySQL. Aunque es posible cambiar el valor admitido a 2, no se permite revertir 2 de vuelta a 1. Para obtener ayuda para cambiar el valor predeterminado, cree una incidencia de soporte técnico.

Para MySQL versión 8.0+, solo puede configurar lower_case_table_names al inicializar el servidor. Más información. Se prohíbe cambiar el valor lower_case_table_names después de inicializar el servidor.

Los valores admitidos para la versión 8.0 de MySQL es 1 y 2 en el servidor flexible de Azure Database for MySQL. El valor predeterminado es 1. Para obtener ayuda para cambiar el valor predeterminado durante la creación del servidor, cree una incidencia de soporte técnico.

innodb_tmpdir

Use el parámetro innodb_tmpdir del servidor flexible de Azure Database for MySQL 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 al almacenamiento temporal (SSD), que está disponible en gibibytes (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 necesita más espacio, puede establecer innodb_tmpdir en /app/work/tmpdir. Este valor utiliza la capacidad de almacenamiento disponible en el servidor flexible de Azure Database for MySQL. Este valor puede ser útil para las operaciones más grandes que requieren un almacenamiento más temporal.

Tenga en cuenta que el uso de resultados /app/work/tmpdir en un rendimiento más lento en comparación con el valor de 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.
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). El parámetro log_bin_trust_function_creators se establece en ON de manera predeterminada en servidores flexibles.

El formato de registro binario siempre es ROW, y las conexiones al servidor siempre 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 puede permitir que log_bin_trust_function_creators permanezca como 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

Para obtener información sobre el parámetro innodb_buffer_pool_size, revise la documentación de MySQL.

El tamaño de memoria física de la tabla siguiente representa la memoria de acceso aleatorio (RAM) disponible en gigabytes (GB) en el servidor flexible de Azure Database for MySQL.

Plan de tarifa	Núcleos virtuales	Tamaño de memoria física (GB)	Valor predeterminado (bytes)	Valor mínimo (bytes)	Valor máximo (bytes)
Ampliable (B1s)	1	1	134217728	33554432	268435456
Ampliable (B1ms)	1	2	536870912	134217728	1073741824
Ampliable (B2s)	2	4	2147483648	134217728	2147483648
Ampliable (B2ms)	2	8	4294967296	134217728	5368709120
Flexible	4	16	12884901888	134217728	12884901888
Flexible	8	32	25769803776	134217728	25769803776
Flexible	12	48	51539607552	134217728	51539607552
Flexible	16	64	2147483648	134217728	2147483648
Flexible	20	80	64424509440	134217728	64424509440
Uso general	2	8	4294967296	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	20	160	128849018880	134217728	128849018880
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. El parámetro de servidor innodb_file_per_table controla este comportamiento.

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 un máximo de 8 terabytes (TB) en un único archivo de datos. Si el tamaño de la base de datos es superior a 8 TB, debe crear la tabla en el espacio de tabla innodb_file_per_table. Si tiene una sola tabla de tamaño superior a 8 TB, debería usar la tabla de particiones.

innodb_log_file_size

El valor de 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 un bloqueo frente a maximizar el rendimiento durante las operaciones máximas. Un tamaño de archivo de registro mayor también puede dar lugar a tiempos de reinicio más largos.

Puede configurar innodb_log_size en 256 megabytes (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 show global status like 'innodb_buffer_pool_pages_dirty' permanece en 0 durante 30 segundos para evitar el retraso de reinicio.

max_connections

El tamaño de memoria del servidor determina el valor de max_connections. El tamaño de memoria física de la tabla siguiente representa la RAM disponible, en gigabytes, en el servidor flexible de Azure Database for MySQL.

Plan de tarifa	Núcleos virtuales	Tamaño de memoria física (GB)	Valor predeterminado	Valor mínimo	Valor máximo
Ampliable (B1s)	1	1	85	10	171
Ampliable (B1ms)	1	2	171	10	341
Ampliable (B2s)	2	4	341	10	683
Ampliable (B2ms)	2	4	683	10	1365
Flexible	4	16	1365	10	2731
Flexible	8	32	2731	10	5461
Flexible	12	48	4097	10	8193
Flexible	16	64	5461	10	10923
Flexible	20	80	6827	10	13653
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	20	160	13653	10	27306
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

Cuando las conexiones superan el límite, puede recibir el siguiente error: "ERROR 1040 (08004): Demasiadas conexiones".

La creación de nuevas conexiones de cliente a MySQL tarda tiempo. Después de establecer estas conexiones, ocupan recursos de base 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 este problema. Para obtener la mejor experiencia posible, se recomienda usar un agrupador de conexiones, como ProxySQL, para administrar las conexiones de forma eficaz. Para obtener información sobre cómo configurar ProxySQL, consulte esta entrada de blog.

Nota:

ProxySQL es una herramienta de la comunidad de código abierto. Microsoft lo admite de la mejor manera posible. Para obtener soporte técnico de producción con instrucciones autoritativas, póngase en contacto con el servicio de soporte técnico de ProxySQL.

innodb_strict_mode

Si recibe un error similar a "Tamaño de fila demasiado grande (> 8126)", es posible que desee desactivar el parámetro de servidor innodb_strict_mode. Este parámetro no se puede modificar globalmente en el nivel de servidor porque si el tamaño de los datos de fila es mayor que 8000, los datos se truncan sin un error. Este truncamiento puede provocar una posible pérdida de datos. Se recomienda modificar el esquema para ajustarlo al límite de tamaño de página.

Puede establecer este parámetro en el nivel de sesión mediante init_connect. Para obtener más información, consulte Establecer parámetros de servidor no modificables.

Nota:

Si tiene un servidor de réplica de lectura, al establecer innodb_strict_mode en OFF en el nivel de sesión en un servidor de origen, se interrumpirá la replicación. Se recomienda mantener el parámetro establecido en ON 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. También puede llamar al procedimiento almacenado y establecer las zonas horarias globales o de nivel de sesión mediante Azure Portal o la CLI de Azure.

binlog_expire_logs_seconds

En el servidor flexible de Azure Database for MySQL, el parámetro binlog_expire_logs_seconds especifica el número de segundos que el servicio espera antes de eliminar 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. El registro binario 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 eliminan 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 eliminarlos.

Si desea conservar registros binarios durante más tiempo, puede configurar el parámetro binlog_expire_logs_seconds. Si binlog_expire_logs_seconds se establece en el valor predeterminado de 0, se elimina un registro binario en cuanto se libera el identificador. Si el valor de binlog_expire_logs_seconds es mayor que 0, el registro binario se elimina después del número de segundos configurado.

Servidor flexible de Azure Database for MySQL controla las características administradas, como la copia de seguridad y la eliminación de réplica de lectura de archivos binarios 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 eliminación de registros binarios antes de que la réplica lea los cambios del elemento primario. Si establece binlog_expire_logs_seconds en un valor superior, los registros binarios no se eliminarán lo suficientemente pronto. Este retraso puede 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_scheduler administra la creación, programación y ejecución de eventos. Es decir, el parámetro administra las tareas que se ejecutan según una programación por un subproceso especial de MySQL Event Scheduler. Cuando el parámetro event_scheduler se establece en ON, el subproceso de Event Scheduler aparece como un proceso de demonio en la salida de SHOW PROCESSLIST.

Para servidores MySQL versión 5.7, el parámetro del servidor event_scheduler se pone automáticamente en "OFF" cuando se inicia la copia de seguridad, y el parámetro del servidor event_scheduler se vuelve a poner en "ON" después de que la copia de seguridad se completa correctamente. En la versión 8.0 de MySQL para Azure Database for MySQL: servidor flexible, event_scheduler sigue sin verse afectado durante las copias de seguridad. Para garantizar operaciones más fluidas, se recomienda actualizar los servidores MySQL 5.7 a la versión 8.0 mediante una actualización de la versión principal.

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>;

Para obtener más información sobre cómo crear un evento, consulte la siguiente documentación sobre Event Scheduler en el manual de referencia de MySQL:

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 de 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) |
| ``` |
| To configure the `event_scheduler` server parameter in Azure Database for MySQL - Flexible Server, perform the following steps: |

1. In the Azure portal, go to your Azure Database for MySQL - Flexible Server instance. Under **Settings**, select **Server parameters**.
1. On the **Server parameters** pane, search for `event_scheduler`. In the **VALUE** dropdown list, select **ON**, and then select **Save**.

    > [!NOTE]
    > Deployment of the dynamic configuration change to the server parameter doesn't require a restart.

1. To create an event, connect to the Azure Database for MySQL - Flexible Server instance and run the following SQL command:
    ```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());

    ```
1. To view the Event Scheduler details, run the following SQL statement:
    ```sql

    SHOW EVENTS;

    ```
    The following output appears:
    ```sql

    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) |
    | ``` |

1. After a few minutes, query the rows from the table to begin viewing the rows inserted every minute according to the `event_scheduler` parameter that you configured:

    ```azurecli
    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) |
    | ``` |
| 1. After an hour, run a `select` statement on the table to view the complete result of the values inserted into table every minute for an hour (as `event_scheduler` is configured in this case): |
    ```azurecli

    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) |
    | ``` |

#### Other scenarios

You can set up an event based on the requirements of your specific scenario. A few examples of scheduling SQL statements to run at various time intervals follow.

To run a SQL statement now and repeat one time per day with no end:

```sql
CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 DAY
STARTS (TIMESTAMP(CURRENT_DATE) + INTERVAL 1 DAY + INTERVAL 1 HOUR)
COMMENT 'Comment'
DO
<your statement>;

Para ejecutar una instrucción SQL cada hora sin fin:

CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 HOUR
COMMENT 'Comment'
DO
<your statement>;

Para ejecutar 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 de servidor event_scheduler se establezca en OFF. Si esto ocurre, cuando se complete la conmutación por error, configure 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 de servidor modificables y no modificables. Los parámetros de servidor no modificables no están disponibles. Puede configurar un parámetro de servidor no modificable en el nivel de sesión mediante init_connect en Azure Portal o la CLI de Azure.

Compartir vía

Parámetros del servidor en Azure Database for MySQL: servidor flexible

¿Cuáles son los parámetros del servidor?

Parámetros configurables del servidor

lower_case_table_names

innodb_tmpdir

log_bin_trust_function_creators

innodb_buffer_pool_size

innodb_file_per_table

innodb_log_file_size

max_connections

innodb_strict_mode

time_zone

binlog_expire_logs_seconds

event_scheduler

Configuración del parámetro de servidor event_scheduler

Limitaciones

Parámetros del servidor no modificables

Comentarios

Recursos adicionales

Compartir vía

Parámetros del servidor en Azure Database for MySQL: servidor flexible

¿Cuáles son los parámetros del servidor?

Parámetros configurables del servidor

lower_case_table_names

innodb_tmpdir

log_bin_trust_function_creators

innodb_buffer_pool_size

innodb_file_per_table

innodb_log_file_size

max_connections

innodb_strict_mode

time_zone

binlog_expire_logs_seconds

event_scheduler

Configuración del parámetro de servidor event_scheduler

Limitaciones

Parámetros del servidor no modificables

Contenido relacionado

Comentarios

Recursos adicionales