Limitations dans Azure Database pour MySQL

  • Article

S’APPLIQUE À : Azure Database pour MySQL - Serveur unique

Important

Azure Database pour MySQL serveur unique se trouve sur le chemin de mise hors service. Nous vous recommandons vivement de procéder à la mise à niveau vers Azure Database pour MySQL serveur flexible. Pour plus d’informations sur la migration vers Azure Database pour MySQL serveur flexible, consultez Ce qui se passe pour Azure Database pour MySQL serveur unique ?

Les sections suivantes abordent la capacité, la prise en charge du moteur de stockage, la prise en charge des privilèges, la prise en charge des instructions de manipulation des données et les limites fonctionnelles du service de base de données. Vous pouvez aussi consulter les limitations générales qui sont applicables au moteur de base de données MySQL.

Paramètres de serveur

Notes

Si vous recherchez des valeurs minimales/maximales pour des paramètres de serveur comme max_connections et innodb_buffer_pool_size, ces informations ont été déplacées vers l’article Paramètres du serveur .

Azure Database pour MySQL prend en charge le réglage des valeurs des paramètres de serveur. La valeur minimale et la valeur maximale de certains paramètres (par ex., max_connections, join_buffer_size, query_cache_size) sont déterminées par le niveau tarifaire et les vCores du serveur. Pour plus d’informations sur ces limites, consultez Paramètres du serveur.

Lors du déploiement initial, un serveur Azure pour MySQL contient des tableaux système pour les informations de fuseau horaire, mais ces tableaux ne sont pas remplis. 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.

Les plug-ins de mot de passe, tels que « validate_password » et « caching_sha2_password », ne sont pas pris en charge par le service.

Moteurs de stockage

MySQL prend en charge de nombreux moteurs de stockage. Sur Azure Database pour MySQL, les moteurs de stockage suivants sont pris en charge ou ne le sont pas :

Prise en charge

Non pris en charge

Prise en charge des privilèges et de la manipulation des données

De nombreux paramètres de serveur peuvent dégrader de façon inattendue les performances du serveur, ou nier les propriétés ACID du serveur MySQL. Afin de préserver l’intégrité du service et le contrat SLA au niveau du produit, ce service n’expose pas plusieurs rôles.

Le service MySQL n’autorise pas l’accès direct au système de fichiers sous-jacent. Certaines commandes de manipulation de données ne sont pas prises en charge.

Non pris en charge

Les éléments suivants ne sont pas pris en charge :

  • Rôle d’administrateur de base de données : Restreint. Sinon, vous pouvez utiliser le rôle d’utilisateur Administrateur (généré lors de la création d’un serveur) qui vous permet d’exécuter la plupart des instructions DDL et DML.
  • Privilège de superutilisateur : de la même façon, le privilège de superutilisateur est limité.
  • DEFINER : requiert des privilèges de superutilisateur pour créer et est limité. Si vous importez des données à l’aide d’une sauvegarde, supprimez les commandes CREATE DEFINER manuellement ou avec la commande --skip-definer lorsque vous effectuez une opération mysqlpump.
  • Bases de données système : La base de données système mysql est en lecture seule ; elle est utilisée pour prendre en charge diverses fonctionnalités PaaS. Vous ne pouvez pas apporter de modifications à la base de données système mysql.
  • SELECT ... INTO OUTFILE: Pas de prise en charge dans le service.
  • LOAD_FILE(file_name): Pas de prise en charge dans le service.
  • Privilège BACKUP_ADMIN : l’octroi de ce privilège n’est pas pris en charge pour effectuer des sauvegardes à l’aide d’utilitaires.

Prise en charge

  • LOAD DATA INFILE est prise en charge, mais le paramètre [LOCAL] doit être spécifié et dirigé vers un chemin d'accès UNC (stockage Azure monté via SMB). En outre, si vous utilisez une version du client MySQL >= 8.0, vous devez inclure le paramètre -–local-infile=1 dans votre chaîne de connexion.

Limitations fonctionnelles

Opérations de mise à l’échelle

  • La mise à l’échelle dynamique vers et depuis les niveaux tarifaires de base n’est pas prise en charge pour le moment.
  • La diminution de la taille de stockage du serveur n’est pas prise en charge.

Mises à niveau des versions principales

Restauration dans le temps

  • Lorsque vous utilisez la fonctionnalité PITR, le nouveau serveur est créé avec la même configuration que le serveur sur lequel il est basé.
  • La restauration d’un serveur supprimé n’est pas prise en charge.

Points de terminaison de service VNet

  • Les points de terminaison de service de réseau virtuel sont uniquement pris en charge pour les serveurs Usage général et Mémoire optimisée.

Taille de stockage

  • Veuillez vous reporter aux niveaux tarifaires pour les limites de taille de stockage par niveau tarifaire.

Problèmes connus

  • L’instance de serveur MySQL affiche la mauvaise version de serveur une fois la connexion établie. Pour obtenir la version de moteur correcte de l’instance de serveur, utilisez la commande select version();.

Étapes suivantes