Amazon RDS pour MySQL vs installation de MySQL sur une instance Amazon EC2
Au travail, nous hébergeons tous nos serveurs Web sur Amazon EC2 et utilisons généralement des bases de données MySQL installées sur la même boîte que notre serveur Web Apache, et communiquons avec eux sur localhost. Nous devons maintenant migrer notre base de données vers son propre serveur pour l'un de nos systèmes. J'ai le choix entre deux solutions: utilisez Amazon RDS , ou lancez simplement une nouvelle boîte Amazon EC2 et installez MySQL dessus.
RDS, étant un service de base de données dédié fourni par la même société que EC2, semble qu'il devrait être l'option évidemment meilleure . Cependant, quand je regarde le prix des deux options (voir http://aws.Amazon.com/ec2/pricing et http://aws.Amazon.com/rds/pricing ) il semble qu'un serveur RDS coûte presque deux fois plus cher qu'un serveur EC2 pour une box aux mêmes spécifications.
Étant donné que je suis capable de gérer moi-même les sauvegardes et que EC2 offre la même capacité de mise à l'échelle de l'instance que RDS, je ne vois aucune raison d'utiliser RDS au lieu d'EC2. Il semble que je manque probablement quelque chose de gros, car si j'avais raison, personne n'utiliserait RDS. Que manque-t-il exactement et quels sont les avantages de RDS par rapport à l'installation de votre propre base de données sur une instance EC2?
Je suis un grand fan d'AWS en général ... mais pas RDS.
@RolandoMySQLDBA a souligné qu'il y avait de très bons points contre cela.
Le seul avantage que je vois dans RDS par rapport à MySQL sur EC2 est la possibilité de faire des clichés pointés et cliqués, des clones et une récupération ponctuelle, mais ceux-ci ne sont pas suffisants pour compenser la perte de contrôle et de flexibilité et ils ne justifie certainement pas le prix plus élevé. Le RDS est sexy à certains égards, mais vous ne pouvez pas faire confiance à ce que vous ne pouvez pas réparer, car vous ne pouvez pas accéder à toutes les pièces mobiles.
Je n'aime pas ne pas avoir le privilège SUPER. Je n'aime pas ne pas pouvoir suivre le journal des erreurs. Je n'aime pas ne pas pouvoir exécuter "top" ou "iostat" sur mon serveur de base de données pour voir comment les cœurs et les lecteurs bénéficient de la charge. Je n'aime pas ne pas avoir accès au moteur de stockage fédéré. Je n'aime pas l'idée de payer pour une machine principale de secours en veille (multi-AZ) que je ne peux même pas utiliser comme réplique en lecture. Bien sûr, il y a des explications parfaitement raisonnables pour lesquelles toutes ces contraintes doivent être en place pour que MySQL soit correctement packagé et vendu sous forme de RDBMS-in-a-box. La seule chose est, RDBMS-in-a-box "résout" toute une série de problèmes que je n'ai pas ... et pénètre dans mon manière, provoquant de nouveaux problèmes.
Mais la rupture absolue pour moi avec RDS est le manque total d'accès aux journaux binaires et à la réplication. Les binlogs, en particulier basés sur des lignes, sont un outil de récupération fantastique pour les catastrophes mineures, mais ils ne vous seront d'aucune utilité si vous ne pouvez pas y accéder. Vous souhaitez configurer un serveur sur site dans votre bureau en tant que réplique en lecture de votre base de données de production dans RDS? Quelque chose à partir duquel faire des sauvegardes locales, des rapports, ont-ils en main pour la reprise après sinistre si quelque chose d’impensable devait arriver à vos données qui vivent dans RDS? C'est une idée à la fois évidente et brillante.
Oups, désolé, l'accès direct à la réplication n'est pas disponible. Bien sûr, vous pouvez payer pour les réplicas en lecture ... mais uniquement comme d'autres instances RDS. Pas une proposition de valeur dans mon livre.
Mise à jour: un changement significatif dans RDS pour MySQL 5.6
Je préfère toujours exécuter mon propre serveur (même dans EC2) plutôt que d'exécuter RDS pour un certain nombre de raisons, notamment le manque de prise en charge de Fonctions définies par l'utilisateur , l'impossibilité d'utiliser le Federated Storage Engine , et l'impossibilité d'avoir ne connexion supplémentaire disponible pour un accès d'urgence ... cependant ...
Amazon a apporté un changement significatif dans MySQL 5.6 pour RDS qui élimine l'une de mes principales objections - peut-être ma plus grande objection: les journaux binaires sont désormais accessibles et vous pouvez exécuter une instance non-RDS en tant qu'esclave, ou connecter d'autres utilitaires au serveur qui lit le flux binlog.
http://docs.aws.Amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Exporting.NonRDSRepl.html
Officiellement, la documentation indique qu'ils l'exposent afin que vous puissiez configurer un esclave dans le but de faire une migration en direct - vous synchronisez le futur serveur maître étranger à partir de l'instance RDS existante en utilisant mysqldump, puis connectez vers RDS en tant qu'esclave pour obtenir un flux de mises à jour en direct via le flux de réplication jusqu'à ce que votre application soit migrée vers le nouveau maître - mais officieusement, vous pouvez le faire de façon continue tant que vous ne vous attendez pas à ce qu'ils prennent en charge vous ... ce qui me semble raisonnable.
Cela a été confirmé dans un récent webinaire , dans une conversation qui commence vers 56:45:
"Vous pouvez le conserver indéfiniment dans un état répliqué ...
"... tant que vous prenez la responsabilité de maintenir la réplication ..."
"Nous ne vous empêchons pas de faire une réplication continue si c'est ce que vous voulez."
Cette nouvelle capacité m'a suffi pour lever mon objection générale à l'utilisation de RDS dans nos instances MySQL de support de site Web publiques, où nous n'utilisons pas FEDERATED ou certaines autres choses autant ou pas du tout.
Donc, je ne suis toujours pas en faveur de cela, mais je ne suis plus contre, car avoir un flux en direct des journaux binaires me remet finalement le contrôle des données en temps réel et la responsabilité de s'assurer qu'aucune transaction n'est perdu dans une panne catastrophique est de retour avec moi, parce que moi, en tant que DBA, je reprends le contrôle - c'est exactement ce que je veux. Avoir un fournisseur tiers pour pointer du doigt ou intenter une action en justice, ou quoi que ce soit, ne récupère pas vos données perdues si elles disparaissent dans un trou noir à l'intérieur d'une boîte noire.
La direction semble aimer "l'idée" de RDS et ne s'oppose pas à la différence de coût, nous lançons donc tous les nouveaux sites Web avec RDS derrière eux.
La restauration point-and-click point-in-time, je l'admets, est une fonctionnalité intéressante de RDS ... elle ne modifie ni ne perturbe votre machine existante - à la place, elle lance une toute nouvelle instance, en utilisant la sauvegarde qui était le plus proche dans le temps du point sélectionné dans le temps, puis applique les binlogs nécessaires pour amener cette nouvelle machine au point dans le temps que vous avez spécifié.
En rapport avec cela, mais dans l'autre sens, il est également possible, maintenant, d'utiliser une stratégie similaire pour migrer une base de données MySQL en direct vers RDS ... vous pouvez connecter un maître RDS (probablement, ce serait un nouveau déploiement) exemple) en tant qu'esclave d'un système existant afin que l'instance RDS ait la version en direct des données au moment où vous y migrez. Contrairement à l'accès aux binlogs RDS pour la réplication sortante, qui ne fonctionne qu'en 5.6, le la réplication entrante est prise en charge dans RDS commençant par 5.5.33 et 5.6.13.
Si la mise à l'échelle des serveurs DB est pas votre tasse de thé , alors Amazon RDS est OK à utiliser car toutes les cloches et les sifflets viennent avec. Ceux qui veulent simplement une HA modérée, des sauvegardes et une mise à l'échelle en bénéficient grandement.
D'un autre côté, si vous voulez faire évoluer le matériel, c'est hors de question pour RDS. Et si vous souhaitez étendre les capacités de MySQL? Malheureusement, cela est hors de question pour de nombreux aspects que l'on souhaiterait.
Par exemple, saviez-vous que deux champs sont plafonnés sur les sept (7) modèles de serveurs RDS?
Notez le tableau suivant sur ces deux options:
MODEL max_connections innodb_buffer_pool_size
--------- --------------- -----------------------
t1.micro 34 326107136 ( 311M)
m1-small 125 1179648000 ( 1125M, 1.097G)
m1-large 623 5882511360 ( 5610M, 5.479G)
m1-xlarge 1263 11922309120 (11370M, 11.103G)
m2-xlarge 1441 13605273600 (12975M, 12.671G)
m2-2xlarge 2900 27367833600 (26100M, 25.488G)
m2-4xlarge 5816 54892953600 (52350M, 51.123G)
On ne vous donne pas le privilège SUPER et il n'y a pas d'accès direct à my.cnf. À la lumière de cela, afin de modifier les options de my.cnf Pour le démarrage, vous devez d'abord créer une liste d'options de paramètres de base de données MySQL et utiliser la fonction RDS CLI (Command Line Interface) pour modifier les options souhaitées. Ensuite, vous devez effectuer cette opération pour importer les nouvelles options:
- Créez un groupe de paramètres DB personnalisé (appelez-le
MySettings) - Téléchargez RDS CLI et configurez un fichier de configuration avec vos informations d'identification AWS
- Exécutez ce qui suit:
./rds-modify-db-parameter-group MySettings --parameters "name=whateveroption,value=whatevervalue,method=immediate" - Modifier à l'aide de la liste d'options de paramètres DB
MySettings - Redémarrez l'instance MySQL RDS
Vous utilisez une API pour mettre à jour une seule variable et effectuer un redémarrage obligatoire de l'instance RDS pour implémenter le changement? C'est un processus assez pénible pour tweek une option.
Si vous souhaitez faire évoluer MySQL, veuillez utiliser EC2. Ensuite, vous pouvez tweek my.cnf À votre guise comme vous l'avez toujours fait et à l'habitude.