Share via

Limitations dans le serveur flexible Azure Database pour MySQL

  • Article

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

Cet article décrit les limitations de Azure Database pour MySQL serveur flexible. Les limitations générales du moteur de base de données MySQL sont également applicables. Si vous souhaitez en savoir plus sur les limites appliquées aux ressources (calcul, mémoire, stockage), consultez l’article sur le calcul et le stockage.

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 dans les concepts des paramètres du serveur.
  • lower_case_table_names valeur ne peut être définie que sur 1 dans Azure Database pour MySQL serveur flexible.

Azure Database pour MySQL serveur flexible prend en charge le réglage des valeurs des paramètres du serveur. Les valeurs minimales et maximales de certains paramètres (par exemple max_connections, join_buffer_size, query_cache_size) sont déterminées par le niveau de calcul et avant votre calcul de la taille du serveur. Pour plus d’informations sur ces limites, consultez Paramètres du serveur.

Clés primaires invisibles générées

Pour MySQL version 8.0 et ultérieure, les clés primaires invisibles générées (GIPK) sont activées par défaut pour toutes les instances de serveur flexibles Azure Database pour MySQL. Les serveurs MySQL 8.0+ ajoutent la colonne invisible my_row_id aux tables et à une clé primaire sur cette colonne, où la table InnoDB est créée sans clé primaire explicite. Pour cette raison, vous ne pouvez pas créer une table ayant une colonne nommée my_row_id , sauf si l’instruction de création de table spécifie également une clé primaire explicite. Plus d’informations Par défaut, les GIPK sont affichés dans la sortie de SHOW CREATE TABLE, SHOW COLUMNS et SHOW INDEX, et sont visibles dans les tables COLUMNS et STATISTICS des schémas d’informations. Pour plus d’informations sur GIPK et ses cas d’utilisation avec data-in-Replication dans Azure Database pour MySQL serveur flexible, reportez-vous à GIPK avec data-in-Replication.

Étapes pour désactiver les GIPK

  • Vous pouvez mettre à jour la valeur du paramètre de serveur sql_generate_invisible_primary_key sur « OFF » en suivant les étapes mentionnées qui décrivent comment mettre à jour un paramètre de serveur à partir du portail Azure ou en utilisant Azure CLI.

  • Vous pouvez également vous connecter à vos instances de serveur flexibles Azure Database pour MySQL et exécuter la commande suivante.

mysql> SET sql_generate_invisible_primary_key=OFF;

lower_case_table_names

Dans Azure Database pour MySQL serveur flexible, la valeur par défaut est lower_case_table_names 1 pour MySQL version 5.7. Si vous avez besoin d’ajuster ce paramètre, nous vous recommandons de contacter notre équipe du support technique pour obtenir des conseils. Il est important de comprendre qu’une fois la valeur de paramètre modifiée à 2, elle n’est pas autorisée à revenir de 2 à 1.

Pour MySQL version 8.0, notez que la modification du paramètre de lower_case_table_names après l’initialisation du serveur est interdite. Plus d’informations Dans Azure Database pour MySQL serveur flexible version 8.0, la valeur par défaut est lower_case_table_names 1. Si vous souhaitez modifier ce paramètre pour 2, nous vous suggérons de créer un serveur MySQL 5.7, de contacter notre équipe du support technique afin d’obtenir de l’aide sur la modification, et ultérieurement, si nécessaire, vous pouvez mettre à niveau le serveur vers la version 8.0.

Moteurs de stockage

MySQL prend en charge de nombreux moteurs de stockage. Sur Azure Database pour MySQL serveur flexible, voici la liste des moteurs de stockage pris en charge et non pris en charge :

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. Ce service n’expose pas plusieurs rôles afin de préserver l’intégrité du service et le contrat SLA au niveau du produit.

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. Vous pouvez également utiliser l’utilisateur administrateur (généré lors de la création d’un serveur) qui vous permet d’effectuer la plupart des instructions DDL et DML.
  • Les privilèges statiques ci-dessous sont restreints.
  • Privilège BACKUP_ADMIN : l’octroi de ce privilège n’est pas pris en charge pour effectuer des sauvegardes à l’aide des utilitaires. Veuillez consulter la section Prise en charge si vous souhaitez obtenir la liste des privilèges dynamiques pris en charge.
  • 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 manuellement les commandes CREATE DEFINER ou utilisez la commande --skip-definer lors de l’exécution de 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.

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.
  • Pour les versions MySQL 8.0 et ultérieures, seuls les privilèges dynamiques mentionnés ci-dessous sont pris en charge.

Limitations fonctionnelles

Haute disponibilité redondante interzone

  • Cette configuration ne peut être définie qu’au moment de la création du serveur.
  • N’est pas pris en charge dans le niveau de calcul Burstable.

Réseau

  • Une fois le serveur créé, il n’est pas possible de changer la méthode de connexion. Si le serveur est créé avec un Accès privé (intégration au réseau virtuel), il ne peut pas être remplacé par un Accès public (adresses IP autorisées) après la création, et vice versa

Opération d’arrêt/démarrage

  • Pas de prise en charge avec les configurations de réplica en lecture (source et réplicas).

Opérations de mise à l’échelle

  • La diminution du stockage du serveur approvisionné n’est pas prise en charge.

Mises à niveau de la version du serveur

  • La migration automatisée entre les versions principales du moteur de base de données n’est pas prise en charge. Si vous souhaitez procéder à une mise à niveau de la version principale, prenez une image mémoire et restaurez-la sur un serveur créé avec la nouvelle version du moteur.

Restaurer un serveur

  • Avec la restauration à un instant dans le passé, les nouveaux serveurs sont créés avec les mêmes configurations de calcul et de stockage que le serveur source sur lequel ils sont basés. Vous pouvez effectuer un scale-down du calcul du serveur nouvellement restauré après sa création.

Comparaison de fonctionnalités

Toutes les fonctionnalités disponibles dans Azure Database pour MySQL serveur unique ne sont pas disponibles dans Azure Database pour MySQL serveur flexible.

Pour obtenir la liste complète des comparaisons de fonctionnalités entre Azure Database pour MySQL serveur unique et Azure Database pour MySQL serveur flexible, reportez-vous au choix de l’option de serveur MySQL appropriée dans Azure.

Étapes suivantes