Choisir l’option MySQL Server appropriée dans Azure

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

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 ?

Avec Azure, vos charges de travail de serveur MySQL peuvent s’exécuter dans une infrastructure en tant que service (IaaS) de machine virtuelle hébergée ou dans une plateforme en tant que service (PaaS) hébergée. PaaS a deux options de déploiement, et il existe des niveaux de service au sein de chaque option de déploiement. Quand vous choisissez entre IaaS et PaaS, vous devez déterminer si vous voulez gérer votre base de données, appliquer des correctifs, ainsi que contrôler les sauvegardes, la sécurité, la surveillance et la mise à l’échelle, ou plutôt déléguer ces opérations à Azure.

Pour prendre votre décision, envisagez les deux options suivantes :

  • Azure Database pour MySQL. Cette option appartient à la catégorie du secteur PaaS et représente un moteur de base de données MySQL entièrement managé basé sur la version stable de l’édition de la communauté MySQL. Cette base de données en tant que service (DBaaS) relationnelle, hébergée sur la plateforme cloud Azure, appartient à la catégorie de secteur PaaS. Avec une instance gérée de MySQL sur Azure, vous pouvez utiliser des fonctionnalités intégrées, par exemple, de mise à jour corrective automatisée, de haute disponibilité, de sauvegardes automatisées, de mise à l’échelle élastique, de sécurité de niveau entreprise, de conformité et de gouvernance, de surveillance et d’alertes, qui requièrent une configuration intensive lorsque MySQL Server est local ou dans une machine virtuelle Azure. Quand vous utilisez MySQL en tant que service, vous payez à l’utilisation avec des options de scale-up ou de scale-out pour bénéficier de plus de contrôle sans interruption. Deux modes de déploiement sont disponibles pour Azure Database pour MySQL optimisé par MySQL Community Edition :

    • Le serveur flexible est un service de base de données prêt pour la production entièrement managé conçu pour un contrôle et une flexibilité plus précis sur les fonctions de gestion de base de données et les paramètres de configuration. L’architecture de serveur flexible permet aux utilisateurs d’opter pour une haute disponibilité au sein d’une même zone de disponibilité et dans plusieurs zones de disponibilité. Les serveurs flexibles offrent de meilleurs contrôles d’optimisation des coûts grâce à la possibilité d’arrêter/de démarrer le serveur et au niveau de calcul burstable, ce qui est idéal pour les charges de travail ne nécessitant pas en permanence une capacité de calcul complète. Un serveur flexible prenant également en charge des instances réservées, il vous permet d’économiser jusqu’à 63 % sur les coûts, ce qui est idéal pour des charges de travail de production dont les exigences en matière de capacité de calcul sont prévisibles. Le service prend en charge la version de la communauté de MySQL 5.7 et 8.0. Le service est aujourd'hui généralement disponible dans diverses régions Azure. Des serveurs flexibles conviennent parfaitement pour de nouveaux développements et la migration de charges de travail de production vers le service Azure Database pour MySQL.

    • Un serveur unique est un service de base de données complètement managé conçu ne nécessiter qu’une personnalisation minimale. La plateforme de serveur unique est conçue pour prendre en charge la plupart des fonctions de gestion de base de données, comme les correctifs, les sauvegardes, la haute disponibilité et la sécurité, avec un minimum de configuration et de contrôle de la part de l’utilisateur. L’architecture est optimisée à des fins de haute disponibilité intégrée avec une disponibilité de 99,99 % sur une seule zone de disponibilité. Elle prend en charge la version de la communauté de MySQL 5.6 (hors service), 5.7 et 8.0. Le service est aujourd'hui généralement disponible dans diverses régions Azure. Les serveurs uniques ne sont parfaitement adaptés que pour des applications existantes utilisant déjà un serveur unique. Il est recommandé de choisir un serveur flexible pour tous les nouveaux développements ou migrations.

  • MySQL sur des machines virtuelles Azure. Cette option s’inscrit dans la catégorie de secteur IaaS. Avec ce service, vous pouvez exécuter le serveur MySQL sur une machine virtuelle managée dans le cadre de la plateforme cloud Azure. Vous pouvez installer toutes les versions et éditions récentes de MySQL sur une machine virtuelle.

Comparer les options de déploiement de MySQL dans Azure

Le tableau suivant liste les principales différences entre ces options :

Attribut Azure Database pour MySQL
Serveur unique
Azure Database pour MySQL
Serveur flexible
MySQL sur des machines virtuelles Azure
Généralités
Disponibilité générale Mise à la disposition générale Mise à la disposition générale Mise à la disposition générale
Contrat de niveau de service (SLA) Contrat SLA de disponibilité de 99,99 % 99,99 % utilisant des zones de disponibilité 99,99 % utilisant des zones de disponibilité
SE sous-jacent Windows Linux Géré par l’utilisateur
Édition MySQL Community Edition Community Edition Édition Community ou Entreprise
Prise en charge de la version de MySQL 5.6 (mise hors service), 5.7 et 8.0 5.7 et 8.0 Toutes les versions
Sélection de la zone de disponibilité pour la colocation d’applications Non Oui Oui
Nom d’utilisateur dans la chaîne de connexion <user_name>@server_name. Par exemple, mysqlusr@mypgServer Nom d’utilisateur uniquement. Par exemple, mysqlusr Nom d’utilisateur uniquement. Par exemple, mysqlusr
Calcul et mise à l’échelle du stockage
Niveaux de calcul De base, Usage général, À mémoire optimisée Burstable, Usage général, À mémoire optimisée Burstable, Usage général, À mémoire optimisée
Mise à l’échelle du calcul Pris en charge (la mise à l’échelle de et vers le niveau De base n’est pas prise en charge) Prise en charge Prise en charge
Taille de stockage 5 Gio à 16Tio De 20 Gio à 16 Tio De 32 Gio à 32 767 Gio
Mise à l’échelle du stockage en ligne Prise en charge Prise en charge Non pris en charge
Mise à l’échelle du stockage automatique Prise en charge Prise en charge Non pris en charge
Mise à l’échelle des E/S par seconde Non pris en charge Prise en charge Non pris en charge
Optimisation des coûts
Prix ​​des instances réservées Prise en charge Prise en charge Prise en charge
Arrêter/démarrer le serveur pour le développement Le serveur peut être arrêté jusqu’à sept jours Le serveur peut être arrêté jusqu’à 30 jours Prise en charge
Références SKU Burstable à faible coût Non pris en charge Prise en charge Prise en charge
Mise en réseau et sécurité
Connectivité réseau - Points de terminaison publics avec pare-feu de serveur.
- Accès privé avec prise en charge de Liaison privée.
- Points de terminaison publics avec pare-feu de serveur.
- Accès privé avec prise en charge de Liaison privée.
- Accès privé avec intégration de réseau virtuel.
- Points de terminaison publics avec pare-feu de serveur.
- Accès privé avec prise en charge de Liaison privée.
SSL/TLS Activé par défaut avec prise en charge de TLS v1.2, 1.1 et 1.0 Activé par défaut avec prise en charge de TLS v1.2, 1.1 et 1.0 Pris en charge avec TLS v1.2, 1.1 et 1.0
Chiffrement des données au repos Pris en charge avec clés gérées par le client (BYOK) Pris en charge avec clés gérées par le service Non pris en charge
Authentification Microsoft Entra Prise en charge Prise en charge Non pris en charge
Support de Microsoft Defender pour le cloud Oui No Non
Audit du serveur Prise en charge Prise en charge Géré par l’utilisateur
Mise à jour corrective et maintenance
Mise à jour corrective du système d’exploitation Automatique Automatique Géré par l’utilisateur
Mise à niveau d’une version mineure de MySQL Automatique Automatique Géré par l’utilisateur
Mise à niveau d’une version majeure sur place de MySQL Pris en charge de 5.6 à 5.7 Non pris en charge Géré par l’utilisateur
Contrôle de la maintenance Géré par le système Managée par le client Géré par l’utilisateur
Fenêtre de maintenance À tout moment dans la fenêtre de 15 heures Fenêtre 1 heure Géré par l’utilisateur
Notification de maintenance planifiée Trois jours Cinq jours Géré par l’utilisateur
Haute disponibilité
Haute disponibilité Haute disponibilité intégrée (sans serveur de secours) Haute disponibilité intégrée (sans serveur de secours), haute disponibilité dans la même zone et redondante interzone avec serveur de secours Géré par l’utilisateur
Redondance de zone Non pris en charge Prise en charge Prise en charge
Positionnement de la zone de secours Non pris en charge Prise en charge Prise en charge
Basculement automatique Oui (tourne un autre serveur) Oui Géré par l’utilisateur
Basculement forcé initié par l’utilisateur Non Oui Géré par l’utilisateur
Basculement d'application transparent Oui Oui Géré par l’utilisateur
Réplication
Prise en charge des réplicas en lecture Oui Oui Géré par l’utilisateur
Nombre de réplicas en lecture pris en charge 5 10 Géré par l’utilisateur
Mode de réplication Asynchrone Asynchrone Géré par l’utilisateur
Prise en charge GTID des réplicas en lecture Prise en charge Prise en charge Géré par l’utilisateur
Prise en charge entre régions (géoréplication) Oui Non pris en charge Géré par l’utilisateur
Scénarios hybrides Pris en charge avec Réplication des données entrantes Pris en charge avec Réplication des données entrantes Géré par l’utilisateur
Prise en charge GTID pour la réplication de données entrantes Prise en charge Non pris en charge Géré par l’utilisateur
Réplication de données sortantes Non pris en charge Prise en charge Prise en charge
Sauvegarde et récupération
Sauvegardes automatisées Oui Oui Non
Rétention des sauvegardes 7 à 35 jours 1 à 35 jours Géré par l’utilisateur
Rétention à long terme des sauvegardes Géré par l’utilisateur Géré par l’utilisateur Géré par l’utilisateur
Exportation des sauvegardes Prise en charge à l’aide de sauvegardes logiques Prise en charge à l’aide de sauvegardes logiques Prise en charge
Limite de restauration dans le temps à tout moment pendant la période de rétention Oui Oui Géré par l’utilisateur
Point de restauration rapide Non Oui Non
Possibilité de restauration sur une autre zone Non pris en charge Oui Oui
Possibilité de restaurer sur un autre réseau virtuel Non Oui Oui
Possibilité de restauration dans une autre région Oui (Géoredondant) Oui (Géoredondant) Géré par l’utilisateur
Possibilité de restaurer un serveur supprimé Oui Oui Non
Récupération d’urgence
DR dans les régions Azure Utilisation de réplicas en lecture entre les régions, sauvegarde géoredondante Utilisation de la sauvegarde géoredondante Géré par l’utilisateur
Basculement automatique Non Non pris en charge Non
Possibilité d’utiliser le même point de terminaison lecture/écriture Non Non pris en charge Non
Surveillance
Intégration Azure Monitor et alertes Prise en charge Prise en charge Géré par l’utilisateur
Supervision des opérations de base de données Prise en charge Prise en charge Géré par l’utilisateur
Query Performance Insight Prise en charge Prise en charge (à l’aide de Workbooks) Géré par l’utilisateur
Journaux d’activité du serveur Prise en charge Prise en charge (à l’aide des journaux de diagnostic) Géré par l’utilisateur
Journaux d’audit Prise en charge Prise en charge Prise en charge
Journaux d’activité d’erreurs Non pris en charge Prise en charge Prise en charge
Prise en charge Azure Advisor Prise en charge Non pris en charge Non pris en charge
Plug-ins
validate_password Non pris en charge En préversion Prise en charge
caching_sha2_password Non pris en charge En préversion Prise en charge
Productivité des développeurs
Gestion de flotte Prise en charge avec Azure CLI, PowerShell, REST et Azure Resource Manager Prise en charge avec Azure CLI, PowerShell, REST et Azure Resource Manager Pris en charge pour les machines virtuelles avec Azure CLI, PowerShell, REST et Azure Resource Manager
Prise en charge Terraform Prise en charge Prise en charge Prise en charge
GitHub Actions Prise en charge Prise en charge Géré par l’utilisateur

Motivations métier pour choisir PaaS ou IaaS

Plusieurs facteurs peuvent influencer si vous choisissez PaaS ou IaaS pour héberger vos bases de données MySQL.

Coût

La réduction des coûts est souvent le facteur principal qui détermine la meilleure solution d’hébergement de vos bases de données. C’est vrai que vous soyez une start-up à court de liquidités ou une équipe dans une société établie qui subit de fortes contraintes budgétaires. Cette section décrit les principes de base de facturation et de licence dans Azure qui s’appliquent à Azure Database pour MySQL et à MySQL sur des machines virtuelles Azure.

Facturation

Azure Database pour MySQL est disponible en tant que service dans plusieurs niveaux avec différents prix pour les ressources. Toutes les ressources sont facturées à un tarif horaire fixe. Pour obtenir les dernières informations sur les niveaux de service, les tailles de calcul et les quantités de stockage actuellement pris en charge, consultez la page de tarification. Vous pouvez ajuster les niveaux de service et les tailles de calcul de manière dynamique pour répondre aux besoins de débit variés de votre application. Vous êtes facturé pour le trafic internet sortant aux tarifs de transfert de données standard.

Avec Azure Database pour MySQL, Microsoft configure, corrige et met à niveau automatiquement le logiciel de base de données. Ces actions automatisées réduisent vos coûts d’administration. En outre, Azure Database pour MySQL offre des fonctionnalités de sauvegardes automatisées. Ces fonctionnalités vous permettent de réaliser d’importantes économies, notamment si vous avez de nombreuses bases de données. Au contraire, avec MySQL sur des machines virtuelles Azure, vous pouvez choisir et exécuter n’importe quelle version de MySQL. Quelle que soit la version de MySQL que vous utilisez, vous payez pour la machine virtuelle approvisionnée, le coût de stockage associé aux données, la sauvegarde, la surveillance des données et le stockage des journaux, ainsi que les coûts associés au type de licence MySQL spécifique utilisé (le cas échéant).

Azure Database pour MySQL offre une haute disponibilité intégrée pour les interruptions de niveau nœud tout en conservant le niveau de service SLA garanti de 99,99 %. Toutefois, pour la haute disponibilité de base de données au sein de machines virtuelles, vous devez utiliser des options de haute disponibilité telles que la réplication MySQL disponibles sur une base de données MySQL. L’utilisation d’une option de haute disponibilité prise en charge ne fournit pas de SLA supplémentaire. Toutefois, pour des coûts supplémentaires et une plus grande charge administrative, elle vous permet d’atteindre une disponibilité de base de données de plus de 99,99 %.

Pour plus d’informations sur les tarifs, consultez les articles suivants :

Administration

Pour de nombreuses entreprises, la décision de migrer vers un service cloud est tout autant liée à l’idée de se décharger de la complexité de l’administration qu’à celle de réduire les coûts.

Avec IaaS, Microsoft :

  • Administre l’infrastructure sous-jacente.
  • Fournit une mise à jour corrective automatisée pour le matériel et le système d’exploitation sous-jacents.

Avec PaaS, Microsoft :

  • Administre l’infrastructure sous-jacente.
  • Fournit une mise à jour corrective automatisée pour le matériel, le système d’exploitation et le moteur de base de données sous-jacents.
  • Gère la haute disponibilité de la base de données.
  • Effectue automatiquement des sauvegardes et réplique toutes les données pour assurer la récupération d’urgence.
  • Chiffre les données au repos et en mouvement par défaut.
  • Analyse votre serveur et fournit des fonctionnalités pour obtenir des informations sur les performances des requêtes et des recommandations en matière de performances

La liste suivante décrit les considérations administratives pour chaque option :

  • Avec Azure Database pour MySQL, vous pouvez continuer à administrer votre base de données. Mais vous n’avez plus besoin de gérer le moteur de base de données, le système d’exploitation ni le matériel. Voici quelques exemples d’éléments que vous pouvez continuer à administrer :

    • Bases de données
    • Connexion
    • Réglage des index
    • Paramétrage des requêtes
    • Audit
    • Sécurité

    Par ailleurs, la configuration de la haute disponibilité vers un autre centre de données requiert une configuration ou une administration minimale ou nulle.

  • Avec MySQL sur des machines virtuelles Azure, vous pouvez contrôler le système d’exploitation et la configuration des instances de serveur MySQL. Vous décidez quand mettre à jour ou à niveau le système d’exploitation et le logiciel de base de données avec une machine virtuelle ainsi que les correctifs à appliquer. Vous choisissez également quand installer des logiciels supplémentaires tels qu’une application antivirus. Certaines fonctionnalités automatisées simplifient de manière significative la gestion des correctifs, la sauvegarde et la haute disponibilité. Vous pouvez contrôler la taille de la machine virtuelle, le nombre de disques et leurs configurations de stockage. Pour plus d’informations, consultez Tailles des machines virtuelles et des services cloud pour Azure.

Il est temps de migrer vers Azure

  • Azure Database pour MySQL est la solution idéale pour des applications cloud quand la productivité des développeurs et la rapidité de mise sur le marché de nouvelles solutions sont essentielles. Avec des fonctionnalités de programmation similaires à DBA, le service est adapté pour les architectes et les développeurs cloud, car il tempère la nécessité de gérer le système d’exploitation et la base de données sous-jacents.

  • Lorsque vous souhaitez éviter le temps et les frais liés à l’acquisition d’un nouveau matériel local, MySQL sur machines virtuelles Azure est la solution adaptée aux applications qui nécessitent un contrôle granulaire et une personnalisation du moteur MySQL, non pris en charge par le service ou nécessitant un accès du système d’exploitation sous-jacent. Cette solution permet également d’effectuer une migration d’applications et de bases de données locales vers Azure en l’état, au cas où Azure Database pour MySQL ne conviendrait pas.

Comme il n’est pas nécessaire de changer la présentation, l’application ni les couches de données, vous économisez en temps et en budget sur le remaniement de votre solution existante. À la place, vous pouvez vous concentrer sur la migration de toutes vos solutions vers Azure et sur l’optimisation des performances requise par la plateforme Azure.

Étapes suivantes