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: utiliser Amazon RDS , ou simplement lancer une nouvelle boîte Amazon EC2 et y installer MySQL.

RDS, étant un service de base de données dédié fourni par la même société que EC2, semble être la meilleure option. 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 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 à point, 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 SUPERprivilège. 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 existe 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 que RDBMS-in-a-box "résout" toute une série de problèmes que je n'ai pas ... et me gêne, causant 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 des fonctions définies par l' utilisateur , l'incapacité d'utiliser le moteur de stockage fédéré et l'impossibilité d'avoir celui- ci connexion supplémentaire disponible pour l'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 le connectez à 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 vous prennent en charge ... ce qui, me semble raisonnable.

Cela a été confirmé lors d'un récent webinaire , dans une conversation qui commence vers 56 h 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 FEDERATEDou certaines des 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 maintenant 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 dans 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 lien 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, la réplication entrante est prise en charge dans RDS à partir de 5.5.33 et 5.6.13.

Si la mise à l'échelle des serveurs DB n'est pas votre tasse de thé , alors Amazon RDS est OK à utiliser car toutes les cloches et les sifflets l'accompagnent. 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?

• max_connections
• innodb_buffer_pool_size

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)

Vous n'avez pas le privilège SUPER et il n'y a pas d'accès direct à my.cnf. À la lumière de cela, pour modifier les my.cnfoptions de démarrage, vous devez d'abord créer une liste d'options de paramètres de base de données MySQL et utiliser le RDS CLI (Command Line Interface)pour modifier les options souhaitées. Ensuite, vous devez effectuer cette opération pour importer les nouvelles options:

• Créer un groupe de paramètres DB personnalisé (appelez-le MySettings)
• Téléchargez la CLI RDS 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 auquel vous avez été habitué.