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, que Microsoft n'utilise plus. Lorsque le terme sera supprimé du logiciel, nous le supprimerons de cet article.
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 le serveur flexible Azure Database pour MySQL, vous pouvez modifier la valeur des différents paramètres du serveur MySQL à l’aide du portail 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 d’un 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 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/tempest commun. - L’autre répertoire
/app/work/tmpdirest 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 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.
| Niveau tarifaire | vCores | Taille de la mémoire physique (Go) | 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 |
| Burstable (B2s) | 2 | 4 | 2147483648 | 134217728 | 2147483648 |
| Burstable (B2ms) | 2 | 8 | 4294967296 | 134217728 | 5368709120 |
| Expansible | 4 | 16 | 12884901888 | 134217728 | 12884901888 |
| Expansible | 8 | 32 | 25769803776 | 134217728 | 25769803776 |
| Expansible | 12 | 48 | 51539607552 | 134217728 | 51539607552 |
| Expansible | 16 | 64 | 2147483648 | 134217728 | 2147483648 |
| Expansible | 20 | 80 | 64424509440 | 134217728 | 64424509440 |
| 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. 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.
Remarque
Si vous avez modifié le paramètre innodb_log_file_size de sa valeur par défaut par défaut, vérifiez si la valeur de show global status like 'innodb_buffer_pool_pages_dirty' reste 0 pendant 30 secondes pour éviter le délai de redémarrage.
max_connections
La taille de mémoire du serveur détermine la valeur de max_connections. La taille de mémoire physique dans le tableau suivant représente la RAM disponible, en gigaoctets, sur votre serveur flexible Azure Database pour MySQL.
| Niveau tarifaire | vCores | Taille de la mémoire physique (Go) | Valeur par défaut | Valeur min | Valeur maximale |
|---|---|---|---|---|---|
| Burstable (B1s) | 1 | 1 | 85 % | 10 | 171 |
| Burstable (B1ms) | 1 | 2 | 171 | 10 | 341 |
| Burstable (B2s) | 2 | 4 | 341 | 10 | 683 |
| Burstable (B2ms) | 2 | 4 | 683 | 10 | 1365 |
| Expansible | 4 | 16 | 1365 | 10 | 2731 |
| Expansible | 8 | 32 | 2731 | 10 | 5461 |
| Expansible | 12 | 48 | 4097 | 10 | 8193 |
| Expansible | 16 | 64 | 5461 | 10 | 10923 |
| Expansible | 20 | 80 | 6827 | 10 | 13653 |
| 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 | 20 | 160 | 13653 | 10 | 27306 |
| 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 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.
Remarque
ProxySQL est un outil communautaire en open source. Microsoft le prend en charge au mieux. Pour obtenir un support de production avec des conseils faisant autorité, contactez l’équipe de support du produit ProxySQL.
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.
Remarque
Si vous avez un serveur de réplica en lecture, la définition de innodb_strict_mode sur OFF au niveau de la session sur un serveur source arrête 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. 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 à la valeur par défaut de 0, un journal binaire est supprimé dès que le handle 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.
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
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 Azure, sélectionnez votre instance de serveur flexible Azure Database pour MySQL. Sous Paramètres, sélectionnez Paramètres du serveur.
Dans le volet Paramètres du serveur, recherchez
event_scheduler. Dans la liste déroulante VALEUR, sélectionnez ACTIVÉ, puis sélectionnez Enregistrer.Remarque
Le déploiement de la modification de configuration dynamique vers le paramètre de serveur ne nécessite pas de redémarrage.
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
selectsur le tableau pour afficher le résultat complet des valeurs insérées dans le tableau toutes les minutes pendant une heure, (carevent_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 de planification d’instructions SQL à exécuter à différents intervalles de temps.
Pour 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>;
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.