Partage 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 existant dans Azure Database pour MySQL – Serveur flexible. Les limitations générales du moteur de base de données MySQL s’appliquent également. Si vous souhaitez découvrir plus d’informations sur les limitations appliquées aux ressources (calcul, mémoire, stockage), consultez l’article sur le calcul et le stockage.

Paramètres de serveur

Azure Database pour MySQL – Serveur flexible prend en charge le réglage des valeurs des paramètres de 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 découvrir plus d’informations sur ces limites, ainsi que les valeurs minimales et maximales pour des paramètres de serveur tels que max_connections et innodb_buffer_pool_size, consultez l’article sur les paramètres de serveur.

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

Pour MySQL version 8.0 et ultérieure, des clés primaires invisibles générées (GIPK) sont activées par défaut pour toutes les instances Azure Database pour MySQL – Serveur flexible.

Les serveurs MySQL 8.0+ ajoutent la colonne invisible my_row_id aux tables et une clé primaire sur cette colonne, lorsque la table InnoDB est créée sans clé primaire explicite. Pour cette raison, vous ne pouvez pas créer de table avec 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 s’affichent dans la sortie de SHOW CREATE TABLE, SHOW COLUMNS et SHOW INDEX. Les GIPK sont également visibles dans les tables INFORMATION_SCHEMA COLUMNS et STATISTICS.

Pour découvrir plus d’informations sur les GIPK et leurs cas d’utilisation avec la réplication des données entrantes, consultez Répliquer des données dans Azure Database pour MySQL – Serveur flexible.

Étapes pour désactiver les GIPK

Si vous souhaitez désactiver une GIPK, vous avez deux options :

lower_case_table_names

Dans Azure Database pour MySQL – Serveur flexible, la valeur par défaut pour lower_case_table_names est 1 pour MySQL version 5.7. Si vous devez ajuster ce paramètre, nous vous recommandons de créer un ticket de support. Il est important de comprendre qu’après avoir remplacé la valeur du paramètre par 2, sa restauration sur 1 n’est pas autorisée.

La modification du paramètre lower_case_table_names après l’initialisation du serveur est interdite pour MySQL version 8.0. Plus d’informations Dans Azure Database pour MySQL – Serveur flexible, la valeur par défaut pour lower_case_table_names est 1 pour MySQL version 8.0. Si vous souhaitez remplacer ce paramètre par 2, nous vous conseillons de créer un serveur MySQL 5.7 et de créer un ticket de support pour obtenir une assistance liée à la modification. Plus tard, vous pourrez mettre à niveau le serveur sur la version 8.0, le cas échéant.

Moteurs de stockage

MySQL prend en charge de nombreux moteurs de stockage. Les listes suivantes montrent les moteurs de stockage qui sont pris en charge et non pris en charge dans Azure Database pour MySQL – Serveur flexible.

Moteurs pris en charge

Moteurs 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 (atomicité, cohérence, isolation, durabilité) du serveur MySQL. Pour maintenir l’intégrité du service et le contrat de niveau de service à un niveau produit, Azure Database pour MySQL – Serveur flexible n’expose pas de nombreux rôles.

Azure Database pour MySQL – Serveur flexible 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.

Privilèges pris en charge

  • LOAD DATA INFILE est pris en charge, mais vous devez spécifier le paramètre [LOCAL] et le diriger vers un chemin d’accès UNC (stockage Azure monté via Server Message Block). Si vous utilisez le client MySQL version 8.0 ou ultérieure, vous devez inclure le paramètre -–local-infile=1 dans votre chaîne de connexion.

  • Pour MySQL version 8.0 et ultérieure, seuls les privilèges dynamiques suivants sont pris en charge :

Privilèges non pris en charge

  • Le rôle Administrateurs Bases de données (DBA) est restreint. Vous pouvez également utiliser le rôle de l’utilisateur administrateur qui est attribué pendant la création d’un serveur. Ce rôle vous permet d’effectuer la plupart des instructions de langage de définition de données (DDL) et de langage de manipulation de données (DML).

  • Les privilèges statiques suivants sont restreints :

  • L’octroi de privilèges BACKUP_ADMIN n’est pas pris en charge pour effectuer des sauvegardes en utilisant des outils de migration.

  • DEFINER requiert des privilèges SUPER pour créer et est limité. Si vous importez des données en utilisant une sauvegarde, supprimez manuellement les commandes CREATE DEFINER ou utilisez la commande --skip-definer lorsque vous effectuez une sauvegarde mysqlpump.

  • La base de données système mysql est en lecture seule et prend en charge diverses fonctionnalités PaaS (platform-as-a-service). Vous ne pouvez pas apporter de modifications à la base de données système mysql.

  • SELECT ... INTO OUTFILE n’est pas pris en charge dans le service.

Limitations fonctionnelles

Haute disponibilité redondante interzone

Vous pouvez uniquement activer la haute disponibilité redondante interzone pendant la création d’un serveur. Cette configuration n’est pas prise en charge au niveau du calcul Burstable.

Network (Réseau)

Vous ne pouvez pas modifier la méthode de connectivité après avoir créé le serveur. Si vous créez le serveur 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érations d’arrêt/de démarrage

Les opérations d’arrêt/de démarrage du serveur ne sont pas prises 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 effectuer une mise à niveau de la version principale, utilisez un vidage et une restauration sur un serveur créé avec la nouvelle version du moteur.

Restaurer un serveur

Avec la restauration à un instant dans le passé, les nouveaux serveurs ont 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 la création du serveur.

Comparaison de fonctionnalités

Les fonctionnalités disponibles dans Azure Database pour MySQL – Serveur unique ne sont pas toutes 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, consultez l’article sur le Choix de l’option de serveur MySQL appropriée dans Azure.

Contenu connexe