Я большой поклонник AWS в целом ... но RDS, не так много.
@RolandoMySQLDBA указал на некоторые довольно хорошие моменты против этого.
Единственное преимущество, которое я вижу в RDS по сравнению с MySQL в EC2, - это возможность делать моментальные и щелчковые снимки, клоны и восстановление на определенный момент времени, но их недостаточно, чтобы компенсировать потерю контроля и гибкости, и они наверняка не оправдывают цену выше. RDS в некотором смысле сексуален, но в конечном итоге вы не можете доверять тому, что не можете в конечном итоге исправить, потому что не можете добраться до всех движущихся частей.
Я не люблю не иметь SUPERпривилегии. Мне не нравится, когда я не могу следить за журналом ошибок. Мне не нравится, когда я не могу запустить top или iostat на моем сервере баз данных, чтобы увидеть, как ядра и диски получают нагрузку. Мне не нравится отсутствие доступа к движку федеративного хранилища. Мне не нравится мысль платить за главный резервный компьютер с горячим резервированием (multi-AZ), который я даже не могу использовать в качестве реплики для чтения. Конечно, есть вполне разумные объяснения, почему все эти ограничения должны быть на месте, чтобы MySQL был успешно упакован и продан как RDBMS-in-a-box. Единственное, что RDBMS-in-a-box "решает" целый ряд проблем, которых у меня нет ... и мешает, вызывая новые проблемы.
Но абсолютным нарушителем для меня с RDS является полное отсутствие доступа к двоичным журналам и репликации. Binlogs, особенно основанные на строках, являются фантастическим инструментом восстановления для мелких бедствий, но они не помогут вам, если вы не можете получить к ним доступ. Хотите настроить локальный сервер в своем офисе как реплику для чтения вашей производственной базы данных в RDS? Что-то, из чего можно делать локальные резервные копии, делать отчеты, иметь под рукой для аварийного восстановления, если что-то невероятное случится с вашими данными, которые живут в RDS? Эта идея одновременно очевидна и гениальна.
К сожалению, прямой доступ к репликации недоступен. Конечно, вы можете платить за реплики чтения ... но только за другие экземпляры RDS. Не ценное предложение в моей книге.
Обновление: одно существенное изменение в RDS для MySQL 5.6
Я до сих пор предпочитаю работаю свой собственный сервер (даже в EC2) в отличие от запуска RDS по ряду причин, в том числе отсутствия поддержки пользовательских функций , невозможность использовать Федеративные Storage Engine , и неспособность иметь один дополнительное подключение доступно для экстренного доступа ... однако ...
Amazon внес значительные изменения в MySQL 5.6 для RDS, что устраняет одно из моих главных возражений - возможно, самое большое мое возражение: двоичные журналы теперь доступны, и вы можете запускать не-RDS экземпляр в качестве ведомого устройства или подключать другие утилиты к сервер, который читает поток binlog.
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Exporting.NonRDSRepl.html
Официально в документации указывается, что они выставляют это так, что вы можете настроить подчиненное устройство для выполнения динамической миграции - вы синхронизируете чужой будущий главный сервер с существующим экземпляром RDS, используя mysqldump, а затем подключаете его к RDS в качестве ведомого получать живую ленту обновлений через поток репликации, пока ваше приложение не будет перенесено на новый мастер - но неофициально вы можете делать это на постоянной основе, пока вы не ожидаете, что они вас поддержат ... что, мне кажется разумным.
Это было подтверждено на недавнем вебинаре в разговоре, который начинается около 56:45:
«Вы можете держать его в реплицированном состоянии бесконечно ...
«... пока вы берете на себя ответственность за поддержание репликации ...»
«Мы не мешаем вам выполнять текущую репликацию, если вы этого хотите».
Этой новой возможности мне было достаточно, чтобы снять все свои возражения против использования RDS в наших общедоступных экземплярах MySQL, поддерживающих веб-сайты, где мы не используем FEDERATEDили некоторые другие вещи в той или иной мере или вообще.
Так что я все еще не за это, но я больше не против, так как наличие прямого потока двоичных журналов в конечном итоге возвращает меня к контролю данных в реальном времени и ответственности за то, чтобы не было никаких транзакций. потерянный в результате катастрофического сбоя снова вернулся ко мне, потому что я, как администратор базы данных, вернулся к контролю - и это именно то, чего я хочу. Наличие стороннего поставщика, на которого можно будет указать пальцем или подать в суд, или что-то еще, не возвращает ваши потерянные данные, если они исчезают в черной дыре внутри черного ящика.
Управлению, похоже, нравится «идея» RDS, и она не возражает против разницы в затратах, поэтому сейчас мы запускаем все новые веб-сайты с RDS.
Я признаю, что восстановление точки и щелчка на момент времени является хорошей функцией в RDS ... она не изменяет и не нарушает работу существующей машины - вместо этого она запускает совершенно новый экземпляр, используя резервную копию, которая была ближе всего к выбранному моменту времени, а затем применяет необходимые блоки журналов, чтобы перенести эту новую машину к указанному вами моменту времени.
В связи с этим, но в другом направлении, теперь также возможно использовать аналогичную стратегию для переноса действующей базы данных MySQL в RDS ... вы можете подключить мастер RDS (предположительно, как правило, это будет недавно развернутый) экземпляр) в качестве ведомого существующей системы, чтобы экземпляр RDS имел оперативную версию данных во время миграции в нее. В отличие от доступа к блокам RDS для внешней репликации, которая работает только в 5.6, внутренняя репликация поддерживается в RDS, начиная с 5.5.33 и 5.6.13.