Paramètres de serveur dans Azure Database pour MySQL – Serveur flexible
S’APPLIQUE À : 
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.
Remarque
Cet article contient des références au terme esclave, un terme que Microsoft n’utilise plus. Lorsque le terme sera supprimé du logiciel, nous le supprimerons de cet article.
Que sont les variables de serveur ?
Le moteur MySQL fournit de nombreux paramètres et variables de serveur différents qui peuvent être utilisés pour configurer et régler le comportement du moteur. Certains paramètres peuvent être définis dynamiquement pendant le runtime, tandis que d’autres sont « statiques », ce qui nécessite un redémarrage du serveur pour les appliquer.
Le serveur flexible Azure Database pour MySQL expose la possibilité de modifier la valeur des différents paramètres du serveur MySQL à l’aide du portail Microsoft Azure et d’Azure CLI pour répondre aux besoins de votre charge de travail.
Paramètres de serveur configurables
Vous pouvez gérer la configuration du serveur flexible Azure Database pour MySQL à l’aide des paramètres de serveur. Les paramètres de serveur sont configurés avec la valeur par défaut et la valeur recommandée 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 de serveur modifiables et non modifiables. Les paramètres de serveur non modifiables sont grisés.
La liste des paramètres de serveur pris en charge s’allonge en permanence. Utilisez l’onglet Paramètres du serveur du Portail Azure pour afficher la liste complète et configurer les valeurs des paramètres du serveur.
Reportez-vous aux sections suivantes pour en savoir plus sur les limites de plusieurs paramètres de serveur couramment mis à jour. Les limites sont déterminées par le niveau de calcul et la taille (vCores) du serveur.
Notes
- 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 (à l’aide d’outils comme les modèles ARM, Terraform, Azure CLI, etc.), votre script doit avoir une provision pour redémarrer le service afin que les paramètres prennent effet même si vous changez les configurations dans le cadre de l’expérience de création.
- Si vous voulez modifier un paramètre de serveur qui n’est pas modifiable pour votre environnement, veuillez ouvrir un élément UserVoice ou voter si les commentaires existent déjà. Cela peut nous aider à établir des priorités.
lower_case_table_names
Pour MySQL version 5.7, la valeur par défaut est 1 dans le serveur flexible Azure Database pour MySQL. Il est important de noter que, bien qu’il soit possible de modifier la valeur prise en charge sur 2, il n’est pas permis de revenir de 2 à 1. Contactez notre équipe du support technique pour obtenir de l’aide sur la modification de la valeur par défaut. Pour MySQL version 8.0+ lower_case_table_names ne peut être configuré que lors de l’initialisation du serveur. Plus d’informations La modification du paramètre lower_case_table_names après l’initialisation du serveur est interdite. Pour MySQL version 8.0, la valeur par défaut est 1 dans le serveur flexible Azure Database pour MySQL. La valeur prise en charge pour MySQL version 8.0 est 1 et 2 dans le serveur flexible Azure Database pour MySQL. Contactez notre équipe su support technique pour obtenir de l’aide sur la modification de la valeur par défaut lors de la création du serveur.
innodb_tmpdir
Le paramètre innodb_tmpdir dans le serveur flexible Azure Database pour MySQL est utilisé 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 SSD de stockage temporaire, disponible en 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 davantage d’espace est nécessaire, vous pouvez définir innodb_tmpdir sur /app/work/tmpdir. Cela utilise votre stockage, la capacité disponible sur votre serveur flexible Azure Database pour MySQL. Cela peut être utile pour les opérations plus volumineuses qui nécessitent un stockage temporaire plus important.
Il est important de noter que l’utilisation de /app/work/tmpdir entraîne une baisse du niveau de performance par rapport au stockage temporaire par défaut (SSD) /mnt/temp. Le choix doit être fait en fonction des exigences spécifiques des opérations.
Les informations fournies pour le innodb_tmpdir s’appliquent aux paramètres innodb_temp_tablespaces_dir, tmpdiret slave_load_tmpdir où la valeur /mnt/temp par défaut est commune, et l’autre répertoire /app/work/tmpdir est disponible pour la configuration d’un stockage temporaire plus important, avec un compromis en matière de performances en fonction des exigences opérationnelles spécifiques.
log_bin_trust_function_creators
Dans le serveur flexible Azure Database pour MySQL, les journaux binaires sont toujours activés (autrement dit,log_bin est défini sur ON). log_bin_trust_function_creators est défini sur 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 ACTIVÉ.
Quand [log_bin_trust_function_creators] est défini sur OFF, si vous tentez de créer des déclencheurs, vous obtenez une erreur similaire à Vous n’avez pas le SUPER privilègelog_bin_trust_function_creators et la journalisation binaire est activée (vous pouvez utiliser la variable moins sécurisée).
innodb_buffer_pool_size
Consultez la documentation MySQL pour en savoir plus sur ce paramètre. La taille de mémoire physique (Go) dans le tableau ci-dessous représente la mémoire vive (RAM) disponible en gigaoctets (Go) sur votre serveur flexible Azure Database pour MySQL.
| Niveau tarifaire | vCore(s) | Taille de la mémoire physique (Gio) | Valeur par défaut (octets) | Valeur minimale (octets) | Valeur maximale (octets) |
|---|---|---|---|---|---|
| Burstable (B1s) | 1 | 1 | 134217728 | 33554432 | 268435456 |
| Burstable (B1ms) | 1 | 2 | 536870912 | 134217728 | 1073741824 |
| Expansible | 2 | 4 | 2147483648 | 134217728 | 2147483648 |
| Usage général | 2 | 8 | 4294967296 | 134217728 | 5368709120 |
| Usage général | 4 | 16 | 12884901888 | 134217728 | 12884901888 |
| Usage général | 8 | 32 | 25769803776 | 134217728 | 25769803776 |
| Usage général | 16 | 64 | 51539607552 | 134217728 | 51539607552 |
| Usage général | 32 | 128 | 103079215104 | 134217728 | 103079215104 |
| Usage général | 48 | 192 | 154618822656 | 134217728 | 154618822656 |
| Usage général | 64 | 256 | 206158430208 | 134217728 | 206158430208 |
| Critique pour l’entreprise | 2 | 16 | 12884901888 | 134217728 | 12884901888 |
| Critique pour l’entreprise | 4 | 32 | 25769803776 | 134217728 | 25769803776 |
| Critique pour l’entreprise | 8 | 64 | 51539607552 | 134217728 | 51539607552 |
| Critique pour l’entreprise | 16 | 128 | 103079215104 | 134217728 | 103079215104 |
| Critique pour l’entreprise | 20 | 160 | 128849018880 | 134217728 | 128849018880 |
| Critique pour l’entreprise | 32 | 256 | 206158430208 | 134217728 | 206158430208 |
| Critique pour l’entreprise | 48 | 384 | 309237645312 | 134217728 | 309237645312 |
| Critique pour l’entreprise | 64 | 504 | 405874409472 | 134217728 | 405874409472 |
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. Ce comportement est contrôlé par le paramètre de serveur innodb_file_per_table. 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 jusqu’à 4 To dans un seul fichier de données. Si la taille de votre base de données est supérieure à 4 To, vous devez créer la table dans l’espace disque logique innodb_file_per_table. Si vous avez une table d’une taille supérieure à 4 To, vous devez utiliser la table de partition.
innodb_log_file_size
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 équilibrer le temps de récupération dans les rares cas d’une récupération après incident plutôt que de maximiser le débit pendant les opérations de pointe. Cela peut également entraîner des temps de redémarrage plus longs. Vous pouvez définir innodb_log_size sur l’une de ces valeurs : 256 Mo, 512 Mo, 1 Go ou 2 Go pour le serveur flexible Azure Database pour MySQL. Le paramètre est statique et nécessite un redémarrage.
Notes
Si vous avez modifié la valeur par défaut du paramètre innodb_log_file_size, vérifiez si la valeur de « show global status like 'innodb_buffer_pool_pages_dirty' » reste à 0 pendant 30 secondes pour éviter un délai de redémarrage.
max_connections
La valeur de max_connection est déterminée par la taille de la mémoire du serveur.
| Niveau tarifaire | vCore(s) | Taille de la mémoire (Gio) | Valeur par défaut | Valeur minimale | Valeur maximale |
|---|---|---|---|---|---|
| Burstable (B1s) | 1 | 1 | 85 % | 10 | 171 |
| Burstable (B1ms) | 1 | 2 | 171 | 10 | 341 |
| Expansible | 2 | 4 | 341 | 10 | 683 |
| Usage général | 2 | 8 | 683 | 10 | 1365 |
| Usage général | 4 | 16 | 1365 | 10 | 2731 |
| Usage général | 8 | 32 | 2731 | 10 | 5461 |
| Usage général | 16 | 64 | 5461 | 10 | 10923 |
| Usage général | 32 | 128 | 10923 | 10 | 21845 |
| Usage général | 48 | 192 | 16384 | 10 | 32 768 |
| Usage général | 64 | 256 | 21845 | 10 | 43691 |
| Critique pour l’entreprise | 2 | 16 | 1365 | 10 | 2731 |
| Critique pour l’entreprise | 4 | 32 | 2731 | 10 | 5461 |
| Critique pour l’entreprise | 8 | 64 | 5461 | 10 | 10923 |
| Critique pour l’entreprise | 16 | 128 | 10923 | 10 | 21845 |
| Critique pour l’entreprise | 32 | 256 | 21845 | 10 | 43691 |
| Critique pour l’entreprise | 48 | 384 | 32 768 | 10 | 65536 |
| Critique pour l’entreprise | 64 | 504 | 43008 | 10 | 86016 |
Lorsque la limite du nombre de connexions est dépassée, vous pouvez recevoir l’erreur suivante :
ERREUR 1040 (08004) : Trop de connexions
Important
Pour une expérience optimale, nous vous recommandons d’utiliser un regroupement de connexions comme ProxySQL pour gérer efficacement les connexions.
La création de connexions clientes à MySQL prend du temps et, une fois établies, ces connexions occupent des 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 cela. Pour en savoir plus sur la configuration de ProxySQL, consultez notre billet de blog.
Notes
ProxySQL est un outil communautaire en open source. Il est pris en charge par Microsoft dans la mesure du possible. Afin d’obtenir un support de production avec une aide faisant autorité, vous pouvez évaluer et contacter le Support produit de ProxySQL.
innodb_strict_mode
Si vous recevez une erreur semblable à « Taille de ligne trop grande (> 8126) », vous pouvez désactiver le paramètre innodb_strict_mode. Le paramètre de serveur innodb_strict_mode ne peut pas être modifié à l’échelle mondiale 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, ce qui peut entraîner une perte potentielle de données. Nous vous recommandons de modifier le schéma pour qu’il corresponde à la limite de taille de page.
Ce paramètre peut être défini au niveau de la session à l’aide de init_connect. Pour définir innodb_strict_mode au niveau de la session, reportez-vous à Définition des paramètres non listés.
Notes
Si vous avez un serveur de réplica en lecture, la désactivation de innodb_strict_mode au niveau de la session sur un serveur source interrompt la réplication. Nous vous suggérons de conserver le paramètre défini sur ON si vous avez des réplicas en lecture.
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. Pour savoir comment appeler la procédure stockée et définir les fuseaux horaires au niveau global ou au niveau de la session, consultez les articles relatifs au Portail Azure ou à Azure CLI.
binlog_expire_logs_seconds
Dans le serveur flexible Azure Database pour MySQL, ce paramètre spécifie le nombre de secondes pendant lesquelles le service attend avant de vider le fichier journal binaire.
Le journal binaire contient des « événements » décrivant 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. Il 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 vidés dès que le descripteur est libéré du service, de la sauvegarde ou du jeu de réplicas. En présence de plusieurs réplicas, les journaux binaires ne sont vidés qu’après que le réplica le plus lent a lu les modifications. Si vous souhaitez conserver les journaux binaires plus longtemps, vous pouvez configurer le paramètre binlog_expire_logs_seconds. Si la valeur du paramètre binlog_expire_logs_seconds est 0, la valeur par défaut, le descripteur du journal binaire est purgé dès sa libération. Si la valeur du paramètre binlog_expire_logs_seconds est > à 0, le descripteur est purgé une fois le nombre de secondes configuré écoulé. Pour le serveur flexible Azure Database pour MySQL, des fonctions managées telles que la sauvegarde et la purge de réplica de lecture des fichiers binaires sont gérées 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 purge des journaux binaires avant que le réplica lise les modifications du fichier primaire. Si vous définissez le paramètre binlog_expire_logs_seconds sur une valeur supérieure, les journaux binaires ne sont pas purgés suffisamment tôt et peuvent occasionner une augmentation de la facturation du stockage.
event_scheduler
Dans le serveur flexible Azure Database pour MySQL, le paramètre de serveur event_schedule gère la création, la planification et l’exécution d’événements, c’est-à-dire des tâches qui s’exécutent selon une planification, et qui sont exécutées par un thread de programmateur d’évènements spécial. Lorsque le paramètre event_scheduler est défini sur ACTIVÉ, le thread du programmateur d’évènements est répertorié en tant que processus démon dans la sortie de SHOW PROCESSLIST. 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>;
Notes
Pour plus d’informations sur la création d’un événement, consultez la documentation du programmateur d'évènements (Event Scheduler) MySQL ici :
Configuration du paramètre du 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)
Pour configurer le paramètre du serveur event_scheduler dans le serveur flexible Azure Database pour MySQL, procédez comme suit :
Dans le portail Microsoft Azure, accédez à votre instance de serveur flexible Azure Database pour MySQL, puis, sous Paramètres, sélectionnez Paramètres du serveur.
Dans le panneau Paramètres de serveur, recherchez
event_scheduler, dans la liste déroulante VALUE, sélectionnez ACTIVÉ, puis Enregistrer.Notes
La modification de la configuration du paramètre de serveur dynamique sera déployée sans redémarrage.
Ensuite, pour créer un événement, connectez-vous à l’instance de serveur flexible Azure Database pour MySQL et exécutez la commande SQL suivante :
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());Pour afficher les détails du programmateur d'évènements (Event Scheduler), exécutez l’instruction SQL suivante :
SHOW EVENTS;Vous obtenez la sortie suivante :
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)Après quelques minutes, interrogez les lignes du tableau pour commencer à afficher les lignes insérées toutes les minutes en fonction du paramètre
event_schedulerque vous avez 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)Après une heure, exécutez une instruction Select sur le tableau pour afficher le résultat complet des valeurs insérées dans le tableau toutes les minutes pendant une heure, car
event_schedulerest configuré dans notre cas.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)
Autres scénarios
Vous pouvez configurer un événement en fonction des exigences de votre scénario spécifique. Voici quelques exemples similaires de programmation d’instructions SQL à exécuter à des intervalles de temps différents.
Exécuter une instruction SQL maintenant et répéter une fois par jour sans 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>;
Exécuter une instruction SQL toutes les heures sans fin
CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 HOUR
COMMENT 'Comment'
DO
<your statement>;
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 « DÉSACTIVÉ ». Si cela se produit, une fois le basculement terminé, configurez le paramètre pour définir la valeur sur « ACTIVÉ ».
Paramètres de serveur non modifiables
Le panneau des paramètres de serveur sur le portail Azure affiche à la fois les paramètres de serveur modifiables et non modifiables. Les paramètres de serveur non modifiables sont grisés. Si vous souhaitez configurer un paramètre de serveur non modifiable au niveau de la session, reportez-vous à l’article Portail Azure ou Azure CLI pour définir le paramètre au niveau de la connexion à l’aide de init_connect.
Étapes suivantes
- Guide pratique pour configurer des paramètres de serveur dans le portail Azure
- Guide pratique pour configurer des paramètres de serveur dans Azure CLI
Commentaires
Bientôt disponible : pendant toute l’année 2024, nous allons éliminer progressivement Problèmes GitHub comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, voir : https://aka.ms/ContentUserFeedback.
Soumettre et afficher des commentaires pour