Paramètres de serveur dans Azure Database pour MySQL – Serveur flexible

Cet article fournit des considérations et des instructions pour la configuration des paramètres de serveur dans Azure Database pour MySQL – Serveur flexible.

Que sont les paramètres du serveur ?

Le moteur MySQL fournit de nombreux paramètres de serveur (également appelés variables) que vous pouvez utiliser pour configurer et régler le comportement du moteur. Certains paramètres peuvent être définis dynamiquement pendant l’exécution. D’autres sont statiques et nécessitent un redémarrage du serveur après leur définition.

Dans Azure Database pour MySQL - Serveur flexible, vous pouvez modifier la valeur de divers paramètres du serveur MySQL à l'aide de l'option Configurer les paramètres du serveur dans Azure Database pour MySQL - Serveur flexible à l'aide du Portail Microsoft Azure et de l'option Configurer les paramètres du serveur dans Azure Database pour MySQL - Serveur flexible à l'aide d’Azure CLI pour répondre aux besoins de votre charge de travail.

Paramètres de serveur configurables

Vous pouvez gérer la configuration d’un serveur flexible Azure Database pour MySQL à l’aide des paramètres du serveur. Les paramètres de serveur sont configurés avec la valeur par défaut et les valeurs recommandées lors de la création du serveur. Le panneau des paramètres du serveur sur le portail Microsoft Azure affiche à la fois les paramètres modifiables et non modifiables. Les paramètres de serveur non modifiables sont indisponibles.

La liste des paramètres de serveur pris en charge s’allonge en permanence. Vous pouvez utiliser le portail Azure pour afficher régulièrement la liste complète des paramètres du serveur et configurer les valeurs.

Si vous modifiez un paramètre de serveur statique à l’aide du portail, vous devez redémarrer le serveur pour que les changements prennent effet. Si vous utilisez des scripts d’automatisation (par le biais d’outils tels que des modèles Azure Resource Manager, Terraform ou Azure CLI), votre script doit disposer d’une provision pour redémarrer le service pour que les paramètres prennent effet, même si vous modifiez la configuration dans le cadre de l’expérience de création.

Si vous souhaitez modifier un paramètre de serveur non modifiable pour votre environnement, publiez une idée par le biais de commentaires de la communauté ou votez si les commentaires existent déjà (ce qui peut nous aider à hiérarchiser).

Les sections suivantes décrivent les limites des paramètres de serveur couramment mis à jour. Le niveau de calcul et la taille (vCores) du serveur déterminent les limites.

lower_case_table_names

Pour MySQL version 5.7, la valeur par défaut de lower_case_table_names est 1 dans le serveur flexible Azure Database pour MySQL. Bien qu’il soit possible de modifier la valeur 2prise en charge, le retour de 2 à 1 n’est pas autorisée. Pour obtenir de l’aide sur la modification de la valeur par défaut, créez un ticket de support.

Pour la version MySQL 8.0+, vous pouvez configurer lower_case_table_names uniquement lorsque vous initialisez le serveur. Plus d’informations La modification du paramètre lower_case_table_names après l’initialisation du serveur est interdite.

La valeur prise en charge pour MySQL version 8.0 1 est 2 dans le serveur flexible Azure Database pour MySQL. La valeur par défaut est 1. Pour obtenir de l’aide sur la modification de la valeur par défaut lors de la création du serveur, créez un ticket de support.

innodb_tmpdir

Vous pouvez utiliser le paramètre innodb_tmpdir dans le serveur flexible Azure Database pour MySQL pour définir le répertoire des fichiers de tri temporaires créés lors des opérations ALTER TABLE en ligne qui régénèrent.

La valeur par défaut de innodb_tmpdir est /mnt/temp. Cet emplacement correspond au stockage temporaire (SSD), disponible en gigaoctets (Gio) avec chaque taille de calcul du serveur. Cet emplacement est idéal pour les opérations qui ne nécessitent pas une grande quantité d’espace.

Si vous avez besoin d’un espace supplémentaire, vous pouvez définir innodb_tmpdir sur /app/work/tmpdir. Ce paramètre utilise la capacité de stockage disponible sur votre serveur flexible Azure Database pour MySQL. Ce paramètre peut être utile pour les opérations plus volumineuses qui nécessitent un stockage temporaire plus important.

N’oubliez pas que l’utilisation /app/work/tmpdir entraîne des performances plus lentes par rapport à la valeur de stockage temporaire par défaut (SSD) /mnt/temp. Choisissez en fonction des exigences spécifiques des opérations.

Les informations fournies pour innodb_tmpdir s’appliquent aux paramètres innodb_temp_tablespaces_dir, tmpdiret slave_load_tmpdir où :

• La valeur par défaut /mnt/temp est commun.
• L’autre répertoire /app/work/tmpdir est disponible pour la configuration d’un stockage temporaire accru, avec un compromis en matière de performances en fonction des exigences opérationnelles spécifiques.

log_bin_trust_function_creators

Dans Azure Database pour MySQL – Serveur flexible, les journaux binaires sont toujours activés (autrement dit,log_bin est défini sur ON). Le paramètre log_bin_trust_function_creators est défini ON par défaut dans les serveurs flexibles.

Le format de journalisation binaire est toujours ROW et toutes les connexions au serveur utilisent toujours la journalisation binaire basée sur les lignes. Avec la journalisation binaire basée sur les lignes, les problèmes de sécurité n’existent pas et la journalisation binaire ne peut pas s’arrêter, ce qui vous permet, en toute sécurité, d’autoriser que log_bin_trust_function_creators reste défini sur ON.

Quand [log_bin_trust_function_creators] est défini sur OFF et que vous tentez de créer des déclencheurs, vous obtenez une erreur similaire à : Vous n’avez pas le SUPER privilège et la journalisation binaire est activée (vous pouvez utiliser la variable log_bin_trust_function_creators moins sécurisée).

innodb_buffer_pool_size

Pour en savoir plus sur le paramètre innodb_buffer_pool_size, consultez la documentation MySQL.

La taille de la mémoire physique dans le tableau suivant représente la mémoire vive (RAM) disponible, en gigaoctets (Go), sur votre serveur flexible Azure Database pour MySQL.

innodb_file_per_table

MySQL stocke la table InnoDB dans différents espaces de stockage en fonction de la configuration que vous avez fournie lors de la création de la table. L’espace disque logique du système est la zone de stockage pour le dictionnaire de données InnoDB. Un espace disque logique de fichier par table contient des données et des index pour une table InnoDB unique, et est stocké dans son propre fichier de données au sein du système de fichiers. Le paramètre de serveur innodb_file_per_table contrôle ce comportement.

La définition de innodb_file_per_table sur OFF amène InnoDB à créer des tables dans l’espace disque logique du système. Autrement, InnoDB crée des tables dans des espaces disques logiques de fichier par table.

Le serveur flexible Azure Database pour MySQL prend en charge un maximum de 8 téraoctets (To) dans un fichier de données unique. Si la taille de votre base de données est supérieure à 8 To, vous devez créer la table dans l’espace de table innodb_file_per_table. Si vous avez une table d’une taille supérieure à 8 To, vous devez utiliser la table de partition.

innodb_log_file_size

La valeur de innodb_log_file_size est la taille en octets de chaque fichier journal dans un groupe de journaux. La taille combinée des fichiers journaux (innodb_log_file_size * innodb_log_files_in_group) ne peut pas dépasser une valeur maximale légèrement inférieure à 512 Go.

Une plus grande taille de fichier journal est préférable pour les performances, mais elle a pour incidence que le temps de récupération après un incident est élevé. Vous devez trouver un équilibre entre le temps de récupération dans le cas rare d'une panne et l'optimisation du débit pendant les périodes de pointe. Une plus grande taille de fichier journal peut également entraîner des temps de redémarrage plus longs.

Vous pouvez configurer innodb_log_size jusqu’à 256 mégaoctets (Mo), 512 Mo, 1 Go ou 2 Go pour Azure Database pour MySQL - Serveur flexible. Le paramètre est statique et nécessite un redémarrage.

max_connections

La taille de mémoire du serveur détermine la valeur de max_connections. La taille de la mémoire physique dans le tableau suivant représente la RAM disponible, en gigaoctets, sur votre serveur flexible Azure Database pour MySQL.

Lorsque les connexions dépassent la limite, vous pouvez recevoir l’erreur suivante : « ERREUR 1040 (08004) : Trop de connexions ».

La création de connexions clientes à MySQL prend du temps. Après avoir établi ces connexions, elles occupent les ressources de base de données, même lorsqu’elles sont inactives. La plupart des applications requièrent de nombreuses connexions à courte durée, ce qui aggrave la situation. Par conséquent, il y a moins de ressources disponibles pour votre charge de travail réelle; ce qui entraîne une diminution des performances.

Un regroupement de connexions qui réduit les connexions inactives et réutilise les connexions existantes permet d’éviter ce problème. Pour une expérience optimale, nous vous recommandons d’utiliser un regroupement de connexions comme ProxySQL pour gérer efficacement les connexions. Pour en savoir plus sur la configuration de ProxySQL, consultez ce billet de blog.

innodb_strict_mode

Si vous recevez une erreur similaire à « Taille de ligne trop grande (> 8126), vous pouvez désactiver le paramètre de serveur innodb_strict_mode. Ce paramètre ne peut pas être modifié globalement au niveau du serveur, car si la taille des données de ligne est supérieure à 8 Ko, les données sont tronquées sans erreur. Cette troncation peut entraîner une perte de données potentielle. Nous vous recommandons de modifier le schéma pour qu’il corresponde à la limite de taille de page.

Vous pouvez définir ce paramètre au niveau de la session, en utilisant init_connect. Pour plus d’informations, consultez Définition des paramètres de serveur non modifiables.

time_zone

Lors du déploiement initial, une instance de serveur flexible Azure Database pour MySQL contient des tables système pour les informations relatives au fuseau horaire, mais ces tables ne sont pas renseignées. Les tables de fuseaux horaires peuvent être remplies en appelant la procédure stockée mysql.az_load_timezone à partir d’un outil tel que la ligne de commande MySQL ou MySQL Workbench. Vous pouvez également appeler la procédure stockée et définir les fuseaux horaires globaux ou au niveau de la session à l’aide du portail Azure ou d’Azure CLI.

binlog_expire_logs_seconds

Dans le serveur flexible Azure Database pour MySQL, ce paramètre binlog_expire_logs_seconds spécifie le nombre de secondes pendant lesquelles le service attend avant de supprimer le fichier journal binaire.

Le journal binaire contient des événements qui décrivent des modifications de base de données, telles que des opérations de création de table ou de modification de données de table. Ce journal binaire contient également des événements pour des instructions susceptibles d’avoir été modifiées. Le journal binaire est principalement utilisé pour les opérations de réplication et les opérations de récupération de données.

En règle générale, les journaux binaires sont supprimés dès que le descripteur est libre de tout service, sauvegarde ou jeu de réplicas. En présence de plusieurs réplicas, les journaux binaires ne sont supprimés qu’après que le réplica le plus lent a lu les modifications.

Si vous souhaitez conserver les journaux binaires pendant une durée plus longue, vous pouvez configurer le paramètre binlog_expire_logs_seconds. Si binlog_expire_logs_seconds est défini sur la valeur par défaut de 0, un journal binaire est supprimé dès que le handle vers celui-ci est libéré. Si la valeur de binlog_expire_logs_seconds est supérieure à 0, le journal binaire est supprimé après le nombre configuré de secondes.

Le serveur flexible Azure Database pour MySQL gère les fonctionnalités gérées, telles que la sauvegarde et la suppression du réplica en lecture des fichiers binaires, en interne. Lorsque vous répliquez les données à partir du serveur flexible Azure Database pour MySQL, ce paramètre doit être défini dans le fichier primaire pour éviter la suppression des journaux binaires avant que le réplica ne lise les modifications du fichier primaire. Si vous définissez binlog_expire_logs_seconds sur une valeur supérieure, les journaux binaires ne seront pas supprimés suffisamment tôt. Cela peut entraîner une facturation du stockage supplémentaire.

event_scheduler

Le serveur flexible Azure Database pour MySQL, le paramètre de serveur event_scheduler gère la création, la planification et l’exécution d’événements. Autrement dit, le paramètre gère les tâches qui s’exécutent selon une planification par un thread de planificateur d’événements MySQL spécial. Lorsque le paramètre event_scheduler est défini sur ON, le thread du programmateur d’évènements est répertorié en tant que processus démon dans la sortie de SHOW PROCESSLIST.

Pour les serveurs MySQL version 5.7, le paramètre du serveur event_scheduler est automatiquement 'OFF' lorsque la sauvegarde est lancée et le paramètre du serveur event_scheduler est réactivé une fois la sauvegarde terminée avec succès. Dans la version 8.0 de MySQL pour Azure Database pour MySQL - serveur flexible, event_scheduler reste inchangé pendant les sauvegardes. Pour garantir un fonctionnement plus fluide, il est recommandé de mettre à niveau vos serveurs MySQL 5.7 vers la version 8.0 à l’aide d’une mise à niveau des versions principales.

Vous pouvez créer et planifier des événements à l’aide de la syntaxe SQL suivante :

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

Pour plus d’informations sur la création d’un événement, consultez la documentation suivante sur le planificateur d’événements dans le manuel de référence MySQL :

• Utilisation du planificateur d’événements dans MySQL 5.7
• Utilisation du planificateur d’événements dans MySQL 8.0

Configurez le paramètre serveur event_scheduler

Le scénario suivant illustre une façon d’utiliser le paramètre event_scheduler dans le serveur flexible Azure Database pour MySQL.

Pour illustrer ce scénario, considérez l’exemple suivant, un tableau simple :

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

Pour exécuter une instruction SQL toutes les heures sans fin :

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

Pour exécuter une instruction SQL tous les jours sans 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>;

Limites

Pour les serveurs avec haute disponibilité configurée, lorsque le basculement se produit, il est possible que le paramètre de serveur event_scheduler soit défini sur OFF. Si cela se produit, une fois le basculement terminé, configurez le paramètre pour définir la valeur sur ON.

Paramètres de serveur non modifiables

Le panneau des paramètres du serveur sur le portail Microsoft Azure affiche à la fois les paramètres de serveur modifiables et non modifiables. Les paramètres de serveur non modifiables sont indisponibles. Vous pouvez configurer un paramètre de serveur non modifiable au niveau de la session à l’aide de init_connect dans le portail Azure ou d’Azure CLI.

Contenu connexe

• Configurez les paramètres du serveur dans Azure Database pour MySQL - Serveur flexible à l'aide du Portail Microsoft Azure
• Configurer les paramètres de serveur dans Azure Database pour MySQL – Serveur flexible à l’aide d’Azure CLI