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.