En tant que base de données open source la plus populaire, MySQL a été implémentée dans de nombreux endroits, des petites startups aux très grandes organisations. Les cas d'utilisation varient de simples applications de site Web à des environnements critiques avec des exigences de disponibilité de 99,999 %. MySQL fait juste le travail et est facile à utiliser.
Bien que MySQL soit relativement facile à gérer, il ne fonctionne pas tout seul. Il y a une certaine surcharge de gestion - le logiciel doit être corrigé de temps en temps, la base de données doit être surveillée pour les échecs ou les anomalies de performances ou de sécurité, les échecs doivent être traités et récupérés, les sauvegardes doivent être gérées... et le la liste est longue. Il n'est donc pas surprenant que les plus grands fournisseurs de cloud proposent des services DBaaS publics basés sur MySQL.
Trois fournisseurs de cloud qui proposent MySQL en tant que service incluent :
- Amazon Web Service avec RDS pour MySQL
- Google Compute Engine avec CloudSQL pour MySQL
- Microsoft Azure, Microsoft Azure MySQL
Dans ce blog, nous comparerons les solutions de ces fournisseurs de cloud.
Version MySQL et correctifs
La dernière version de MySQL disponible dans Amazon Web Services (AWS) est MySQL 8.0.20, qui est assez proche de la dernière version officielle d'Oracle MySQL (8.0.21 au moment de en écrivant). Outre la dernière version, AWS RDS fournit également l'ancienne version de MySQL (versions majeures 5.5, 5.6 et 5.7), afin que vous puissiez déployer la version exacte compatible avec votre application.
Dans Google Cloud Platform (GCP), la version MySQL prise en charge dans CloudSQL pour MySQL est toujours MySQL 5.6 et 5.7, la dernière version mineure de la version 5.6 est 5.6.42 tandis que pour la version 5.7, la dernière la version mineure est 5.7.25.
La base de données Azure pour MySQL prend en charge les versions 5.6, 5.7, 8.0, malheureusement ils ne fournissent pas la version mineure (ou la version de correction de bogue de la base de données, comme l'appelle Azure) lors du déploiement à partir de la console. Pour déterminer la version de votre instance de serveur MySQL, on peut utiliser le SELECT VERSION(); commande à l'invite MySQL.
Problèmes connus et limites
Il existe des problèmes connus et des restrictions qui existent sur la base de données en tant que service alors que cela ne se produit pas dans MySQL sur site ou sur les machines virtuelles. Sur RDS, certaines des limitations sont :
- Le plug-in de trousseau de clés MySQL n'est pas pris en charge.
- La taille maximale de la limite de stockage pour une table est de 16 To lors de l'utilisation du moteur de stockage InnoDB.
- Certains paramètres nécessitent des considérations particulières lors de l'utilisation de RDS, par exemple :long_query_time, lower_case_table_name.
Il existe certaines limitations et problèmes connus dans CloudSQL pour MySQL, divisés en différentes catégories, par exemple :problèmes de durabilité et de disponibilité des données, problèmes de connexion d'instance, problèmes administratifs et problèmes d'exportation et d'importation de données. Chaque catégorie présente des problèmes et des limites spécifiques, dont voici quelques-uns :
- Les opérations de longue durée ne peuvent pas être annulées ou arrêtées.
- Les noms d'instance ne peuvent pas être utilisés immédiatement après la suppression de l'instance.
- La clause DEFINER entraînera l'échec de l'importation.
La base de données Azure pour MySQL présente certaines limitations et problèmes connus liés à la mise à niveau, aux privilèges et au moteur de stockage. Certains des détails sont :
- La mise à niveau majeure de la base de données n'est actuellement pas prise en charge. Vous devez effectuer un vidage et une restauration sur un nouveau serveur pour une mise à niveau majeure.
- La base de données Azure pour MySQL prend actuellement en charge les moteurs de stockage InnoDB et Memory.
- La base de données système dans la base de données Azure pour MySQL est définie en lecture seule. Vous ne pouvez rien changer dans la base de données du système mysql.
Vous devez vérifier les limitations et les problèmes connus de MySQL sur chaque fournisseur de cloud, et comparer avec vos exigences pour comprendre si cela a un impact sur l'application.
Sauvegarde et restauration
Amazon RDS pour MySQL exécute la sauvegarde automatisée selon la planification, il prend un instantané de volume de l'instance de base de données. La valeur par défaut de la période de conservation des sauvegardes est de 7 jours. De plus, RDS télécharge vos journaux de transactions pour les instances de base de données sur S3 toutes les 5 minutes pour conserver la récupération à un instant donné.
Vous pouvez restaurer une sauvegarde à un moment précis en créant une nouvelle instance pendant la période de conservation des sauvegardes. Vous pouvez choisir la dernière heure de restauration pour restaurer la dernière heure possible, ou vous pouvez choisir une personnalisation pour définir une heure spécifique pour la restauration des données.
La sauvegarde effectuée dans CloudSQL pour MySQL est incrémentielle. Il ne contient que les changements de données après la sauvegarde précédente. La sauvegarde la plus ancienne est similaire à la taille actuelle de votre base de données. Lorsque la sauvegarde la plus ancienne est supprimée, la taille de la sauvegarde la plus ancienne suivante augmente, de sorte que la sauvegarde complète existe toujours.
La sauvegarde automatisée se produit tous les jours et elle est conservée pendant 7 jours par défaut. CloudSQL stocke les données de sauvegarde dans 2 régions pour la redondance. Une région peut être dans la même région que celle où l'instance est en cours d'exécution, et l'autre dans une région différente.
La récupération à un moment donné dans CloudSQL créera une nouvelle instance, le paramètre d'instance héritera de la source de l'instance. Avant de procéder à la récupération à un moment donné, assurez-vous que vous avez déjà activé la journalisation binaire. Lorsque vous effectuez une récupération ponctuelle, il vous suffit de renseigner le nom du journal binaire et la position de récupération.
La base de données Azure pour MySQL prend en charge la sauvegarde des fichiers de données et les journaux des transactions. Le calendrier de sauvegarde lui-même est une combinaison de sauvegarde complète et différentielle pour les serveurs avec une taille de stockage allant jusqu'à 4 To, tandis que la sauvegarde d'instantané se produit pour un serveur de stockage jusqu'à 16 To maximum.
La sauvegarde complète s'exécute une fois par semaine, tandis que les sauvegardes différentielles se produisent deux fois par jour. La période de rétention par défaut de la sauvegarde est de 7 jours, mais vous pouvez toujours configurer la rétention jusqu'à 35 jours.
Il existe deux types de restauration dans la base de données Azure pour MySQL, à savoir :
- Restauration ponctuelle, disponible en tant qu'option de sauvegarde de redondance, ou vous pouvez créer un nouveau serveur dans la même région que votre serveur d'origine, en utilisant la sauvegarde complète et le journal des transactions pour restaurer les données.
- Géo-restauration, disponible si vous configurez une géo-redondance dans l'option de stockage. Cela vous permettra de restaurer votre sauvegarde dans différentes régions.
Veuillez noter que ni AWS, Google ou Azure ne vous permettent de télécharger vos sauvegardes.
Surveillance de la base de données
RDS fournit une intégration de surveillance avec CloudWatch, vous pouvez voir certaines des métriques telles que l'utilisation du processeur, les connexions DB, les IOPS en écriture et en lecture, le débit en écriture et en lecture, la latence en écriture et en lecture. Vous pouvez créer une alarme pour déclencher l'alerte depuis CloudWatch, en fonction de certaines catégories de métriques et définir simplement le seuil.
Semblable à RDS, GCP CloudSQL s'intègre également à stackdriver, vous pouvez voir des métriques telles que :l'utilisation du processeur, l'utilisation de la mémoire, les connexions actives, les transactions/s, les octets d'entrée/de sortie, les opérations d'écriture et de lecture, le décalage de réplication .
La base de données Azure pour MySQL fournit certaines métriques, par exemple ; Connexions actives, pourcentage de CPU, échec de connexion, pourcentage d'E/S, pourcentage de mémoire, décalage de réplication, pourcentage de stockage, stockage utilisé. Vous pouvez également créer des alertes dans les bases de données Azure pour MySQL, choisir les métriques et définir les règles.
Conclusion
Basé sur 4 domaines clés ; Version et correctifs de MySQL, problèmes connus et limitations, sauvegarde et restauration, surveillance de la base de données, à mon avis, Amazon RDS pour MySQL est toujours la meilleure base de données en tant que service pour MySQL. Il fournit des versions et des correctifs détaillés, des problèmes et des limitations très limités par rapport aux autres. C'est un moyen pratique d'exécuter MySQL, avec la mise en garde que le prix du service a augmenté ces dernières années.
