Partager via

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

Cet article fournit des points à prendre en considérations et des instructions pour configurer les 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 de serveur ?

Le moteur MySQL fournit de nombreux paramètres de serveur (également appelés variables) que vous pouvez utiliser pour configurer et ajuster le comportement d’un 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 les avoir définis.

Dans Azure Database pour MySQL – Serveur flexible, vous pouvez changer la valeur de divers paramètres de serveur MySQL à l’aide de Configurer les paramètres de serveur dans Azure Database pour MySQL – Serveur flexible à l’aide du portail Microsoft Azure et de Configurer les paramètres de 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 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 ne sont pas disponibles.

La liste des paramètres de serveur pris en charge s’allonge sans arrêt. Vous pouvez utiliser le portail Azure pour voir régulièrement la liste complète des paramètres de 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 Azure Database pour MySQL – Serveur flexible. 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 MySQL version 8.0+, vous pouvez configurer lower_case_table_names uniquement lorsque vous initialisez le serveur. En savoir plus. Le changement du paramètre lower_case_table_names après l’initialisation du serveur est interdit.

Les valeurs prises en charge pour MySQL version 8.0 sont 1 et 2 dans Azure Database pour MySQL – Serveur flexible. La valeur par défaut est 1. Pour obtenir de l’aide sur le changement 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 Azure Database pour MySQL – Serveur flexible pour définir le répertoire des fichiers de tri temporaires créés lors des opérations ALTER TABLE en ligne qui reconstruisent.

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 de davantage d’espace, 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 de plus grande envergure qui nécessitent un stockage temporaire plus important.

N’oubliez pas que l’utilisation de /app/work/tmpdir entraîne des performances plus lentes par rapport à la valeur du stockage temporaire par défaut (SSD)/mnt/temp. Faites votre choix 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 termes 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 risquez d’obtenir 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 découvrir le paramètre innodb_buffer_pool_size, consultez la documentation de 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.

Taille de calcul vCores Taille de la mémoire physique (Go) Valeur par défaut (octets) Valeur minimale (octets) Valeur maximale (octets)
Burstable
Standard_B1s 1 1 134217728 33554432 268435456
Standard_B1ms 1 2 536870912 134217728 1073741824
Standard_B2s 2 4 2147483648 134217728 2147483648
Standard_B2ms 2 8 4294967296 134217728 5368709120
Standard_B4ms 4 16 12884901888 134217728 12884901888
Standard_B8ms 8 32 25769803776 134217728 25769803776
Standard_B12ms 12 48 51539607552 134217728 32212254720
Standard_B16ms 16 64 2147483648 134217728 51539607552
Standard_B20ms 20 80 64424509440 134217728 64424509440
Usage général
Standard_D2ads_v5 2 8 4294967296 134217728 5368709120
Standard_D2ds_v4 2 8 4294967296 134217728 5368709120
Standard_D4ads_v5 4 16 12884901888 134217728 12884901888
Standard_D4ds_v4 4 16 12884901888 134217728 12884901888
Standard_D8ads_v5 8 32 25769803776 134217728 25769803776
Standard_D8ds_v4 8 32 25769803776 134217728 25769803776
Standard_D16ads_v5 16 64 51539607552 134217728 51539607552
Standard_D16ds_v4 16 64 51539607552 134217728 51539607552
Standard_D32ads_v5 32 128 103079215104 134217728 103079215104
Standard_D32ds_v4 32 128 103079215104 134217728 103079215104
Standard_D48ads_v5 48 192 154618822656 134217728 154618822656
Standard_D48ds_v4 48 192 154618822656 134217728 154618822656
Standard_D64ads_v5 64 256 206158430208 134217728 206158430208
Standard_D64ds_v4 64 256 206158430208 134217728 206158430208
Critique pour l’entreprise
Standard_E2ds_v4 2 16 12884901888 134217728 12884901888
Standard_E2ads_v5, Standard_E2ds_v5 2 16 12884901888 134217728 12884901888
Standard_E4ds_v4 4 32 25769803776 134217728 25769803776
Standard_E4ads_v5, Standard_E4ds_v5 4 32 25769803776 134217728 25769803776
Standard_E8ds_v4 8 64 51539607552 134217728 51539607552
Standard_E8ads_v5, Standard_E8ds_v5 8 64 51539607552 134217728 51539607552
Standard_E16ds_v4 16 128 103079215104 134217728 103079215104
Standard_E16ads_v5, Standard_E16ds_v5 16 128 103079215104 134217728 103079215104
Standard_E20ds_v4 20 160 128849018880 134217728 128849018880
Standard_E20ads_v5, Standard_E20ds_v5 20 160 128849018880 134217728 128849018880
Standard_E32ds_v4 32 256 206158430208 134217728 206158430208
Standard_E32ads_v5, Standard_E32ds_v5 32 256 206158430208 134217728 206158430208
Standard_E48ds_v4 48 384 309237645312 134217728 309237645312
Standard_E48ads_v5, Standard_E48ds_v5 48 384 309237645312 134217728 309237645312
Standard_E64ds_v4 64 504 405874409472 134217728 405874409472
Standard_E64ads_v5 , Standard_E64ds_v5 64 512 412316860416 134217728 412316860416
Standard_E80ids_v4 80 504 405874409472 134217728 405874409472
Standard_E96ds_v5 96 672 541165879296 134217728 541165879296

innodb_file_per_table

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

Si innodb_file_per_table est défini sur OFF, InnoDB crée des tables dans l’espace de table système. Autrement, InnoDB crée des tables dans des espaces de table de fichier par table.

Azure Database pour MySQL – Serveur flexible prend en charge un maximum de 8 téraoctets (To) dans un seul fichier de données. 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é 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 tout délai de redémarrage.

connexions_maximales

La taille de la 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.

Taille de calcul vCores Taille de la mémoire physique (Go) Valeur par défaut Valeur minimale Valeur maximale
Burstable
Standard_B1s 1 1 85 10 171
Standard_B1ms 1 2 171 10 341
Standard_B2s 2 4 341 10 683
Standard_B2ms 2 4 683 10 1365
Standard_B4ms 4 16 1365 10 2731
Standard_B8ms 8 32 2731 10 5461
Standard_B12ms 12 48 4097 10 8193
Standard_B16ms 16 64 5461 10 10923
Standard_B20ms 20 80 6827 10 13653
Usage général
Standard_D2ads_v5 2 8 683 10 1365
Standard_D2ds_v4 2 8 683 10 1365
Standard_D4ads_v5 4 16 1365 10 2731
Standard_D4ds_v4 4 16 1365 10 2731
Standard_D8ads_v5 8 32 2731 10 5461
Standard_D8ds_v4 8 32 2731 10 5461
Standard_D16ads_v5 16 64 5461 10 10923
Standard_D16ds_v4 16 64 5461 10 10923
Standard_D32ads_v5 32 128 10923 10 21 845
Standard_D32ds_v4 32 128 10923 10 21 845
Standard_D48ads_v5 48 192 16384 10 32 768
Standard_D48ds_v4 48 192 16384 10 32 768
Standard_D64ads_v5 64 256 21 845 10 43691
Standard_D64ds_v4 64 256 21 845 10 43691
Critique pour l’entreprise
Standard_E2ds_v4 2 16 1365 10 2731
Standard_E2ads_v5, Standard_E2ds_v5 2 16 1365 10 2731
Standard_E4ds_v4 4 32 2731 10 5461
Standard_E4ads_v5, Standard_E4ds_v5 4 32 2731 10 5461
Standard_E8ds_v4 8 64 5461 10 10923
Standard_E8ads_v5, Standard_E8ds_v5 8 64 5461 10 10923
Standard_E16ds_v4 16 128 10923 10 21 845
Standard_E16ads_v5, Standard_E16ds_v5 16 128 10923 10 21 845
Standard_E20ds_v4 20 160 13653 10 27306
Standard_E20ads_v5, Standard_E20ds_v5 20 160 13653 10 27306
Standard_E32ds_v4 32 256 21 845 10 43691
Standard_E32ads_v5, Standard_E32ds_v5 32 256 21 845 10 43691
Standard_E48ds_v4 48 384 32 768 10 65536
Standard_E48ads_v5, Standard_E48ds_v5 48 384 32 768 10 65536
Standard_E64ds_v4 64 504 43008 10 86 016
Standard_E64ads_v5, Standard_E64ds_v5 64 512 43691 10 87 383
Standard_E80ids_v4 80 504 43008 10 86 016
Standard_E96ds_v5 96 672 50000 10 100000

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

La création de connexions clientes à MySQL prend du temps. Une fois ces connexions établies, elles occupent les ressources de base de données, même lorsqu’elles sont inactives. La plupart des applications requièrent de nombreuses connexions de courte durée, ce qui aggrave la situation. Moins de ressources sont disponibles pour votre charge de travail effective, ce qui entraîne une baisse 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 découvrir comment configurer ProxySQL, consultez ce billet de blog.

Remarque

ProxySQL est un outil open source de la communauté. Microsoft le prend en charge au mieux. Pour obtenir un support de production avec des conseils fiables, contactez lesupport du produit ProxySQL.

innodb_strict_mode

Si vous recevez une erreur similaire à « Taille de ligne trop grande (> 8126), vous voudrez peut-être 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 la 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.

fuseau horaire

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 Azure Database pour MySQL – Serveur flexible, le paramètre binlog_expire_logs_seconds spécifie le nombre de secondes qu’attend le service 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 les opérations de création de table ou les modifications dans les 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 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.

planificateur_d'événements

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 ( Event Scheduler) 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 de serveur event_scheduler est automatiquement 'OFF' lorsque la sauvegarde est lancée et le paramètre de serveur event_scheduler est réactivé sur 'ON' une fois la sauvegarde terminée avec succès. Dans MySQL version 8.0 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 majeures.

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 programmateur d’événements dans le manuel de référence de MySQL :

Configurer le paramètre de serveur event_scheduler

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

Pour illustrer ce scénario, prenons l’exemple suivant d’une table 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 tel est le cas, une fois le basculement terminé, configurez le paramètre pour définir la valeur sur ON.

innodb_ft_user_stopword_table

innodb_ft_user_stopword_table est un paramètre de serveur dans MySQL qui spécifie le nom de la table contenant des mots vides personnalisés pour la recherche en texte intégral InnoDB. La table doit se trouver dans la même base de données que la table indexée en texte intégral, et sa première colonne doit être de type VARCHAR. Dans Azure Database pour MySQL – Serveur flexible, la valeur par défaut sql_generate_invisible_primary_key=ON fait que toutes les tables sans clé primaire explicite incluent automatiquement une clé primaire invisible. Ce comportement est en conflit avec les exigences pour innodb_ft_user_stopword_table, car la clé primaire invisible devient la première colonne de la table, ce qui l’empêche de fonctionner comme attendu lors d’une recherche en texte intégral. Pour résoudre ce problème, vous devez définir sql_generate_invisible_primary_key=OFF dans la même session avant de créer la table de mots vides personnalisés. Par exemple :

SET sql_generate_invisible_primary_key = OFF;
CREATE TABLE my_stopword_table (
    stopword VARCHAR(50) NOT NULL
);
INSERT INTO my_stopword_table (stopword) VALUES ('and'), ('or'), ('the');

Ceci garantit que la table de mots vides répond aux exigences de MySQL et permet aux mots vides personnalisés de fonctionner correctement.

Paramètres de serveur non modifiables

Le volet Paramètres de serveur dans le portail 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 en utilisant init_connect dans le portail Azure ou Azure CLI.

Variables système Azure mysql

azure_server_name

La azure_server_name variable fournit le nom exact du serveur d’Azure Database pour MySQL - Instance de serveur flexible. Cette variable est utile lorsque les applications ou les scripts doivent récupérer par programmation le nom d’hôte du serveur auquel ils sont connectés, sans s’appuyer sur des configurations externes et peuvent être récupérés en exécutant la commande suivante dans MySQL.

mysql> SHOW GLOBAL VARIABLES LIKE 'azure_server_name';
+-------------------+---------+
| Variable_name     | Value   |
+-------------------+---------+
| azure_server_name | myflex  |
+-------------------+---------+

Remarque : Le azure_server_name renvoie systématiquement le nom de serveur original que vous utilisez pour vous connecter au service (par exemple, myflex) pour les serveurs avec haute disponibilité activée ou désactivée.

nom_serveur_logique

La logical_server_name variable représente le nom d’hôte de l’instance où Azure Database pour MySQL - Serveur flexible est en cours d’exécution. Cette variable est utile pour identifier l’hôte sur lequel le service est en cours d’exécution, ce qui facilite la résolution des problèmes et la surveillance du basculement. Vous pouvez récupérer cette variable en exécutant la commande suivante dans MySQL.

mysql> SHOW GLOBAL VARIABLES LIKE 'logical_server_name';
+---------------------+--------------+
| Variable_name       | Value        |
+---------------------+--------------+
| logical_server_name | myflex	     |
+---------------------+--------------+

Remarque : Pour un serveur à haute disponibilité, la logical_server_name variable reflète le nom d’hôte de l’instance agissant comme serveur principal. Pour un serveur sur lequel la haute disponibilité est désactivée, la valeur est logical_server_name la même que la azure_server_name variable, car il n’existe qu’une seule instance.

Contenu connexe