На работе мы размещаем все наши веб-серверы на Amazon EC2 и обычно используем базы данных MySQL, установленные на том же компьютере, что и наш веб-сервер Apache, и общаемся с ними localhost. Теперь мы сталкиваемся с необходимостью перенести нашу базу данных на собственный сервер для одной из наших систем. У меня есть выбор между двумя решениями: использовать Amazon RDS или просто запустить новую коробку Amazon EC2 и установить на нее MySQL.

RDS, будучи выделенной базой данных, предоставляемой той же компанией, что и EC2, кажется, что это должен быть явно лучший вариант. Однако, когда я смотрю на цены для двух вариантов (см. Http://aws.amazon.com/ec2/pricing и http://aws.amazon.com/rds/pricing ), кажется, что сервер RDS стоит почти вдвое больше, чем сервер EC2 для коробки с теми же характеристиками.

Учитывая, что я способен самостоятельно обрабатывать резервные копии и что EC2 предлагает такую ​​же возможность масштабирования экземпляра, как это требуется для RDS, я не вижу никакой причины использовать RDS вместо EC2. Кажется, что я, вероятно, упускаю что-то большое, потому что, если бы я был прав, никто бы не использовал RDS. Что именно мне не хватает, и каковы преимущества RDS по сравнению с установкой вашей собственной базы данных на экземпляр EC2?

Я большой поклонник 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.

Если масштабирование БД-серверов не является вашей чашкой чая , то Amazon RDS можно использовать, потому что с ним все навороты. Те, кто просто хочет умеренную HA, резервные копии и масштабирование, получают большую выгоду.

С другой стороны, если вы хотите увеличить аппаратное обеспечение, это не может быть и речи о RDS. Что если вы хотите расширить возможности MySQL? К сожалению, о многих аспектах этого не может быть и речи.

Например, знаете ли вы, что два поля ограничены всеми семью (7) моделями RDS-серверов?

• max_connections
• innodb_buffer_pool_size

Обратите внимание на следующую таблицу для этих двух вариантов:

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)

Вы не получили привилегию SUPER и не имеете прямого доступа к my.cnf. В свете этого, чтобы изменить my.cnfпараметры запуска, вы должны сначала создать список параметров БД на основе MySQL и использовать их RDS CLI (Command Line Interface)для изменения требуемых параметров. Затем вы должны сделать это, чтобы импортировать новые параметры:

• Создать пользовательскую группу параметров БД (назовите ее MySettings)
• Загрузите RDS CLI и настройте файл конфигурации с вашими учетными данными AWS
• Выполните следующее: ./rds-modify-db-parameter-group MySettings --parameters "name=whateveroption,value=whatevervalue,method=immediate"
• Изменить с помощью списка опций параметров БД MySettings
• Перезапустите экземпляр MySQL RDS

Использование API для обновления одной переменной и принудительного перезапуска экземпляра RDS для реализации изменения? Это довольно болезненный процесс, чтобы настроить любой вариант.

Если вы хотите увеличить MySQL, пожалуйста, используйте EC2. Затем вы можете настроить my.cnfпо своему вкусу, как вы всегда делали и привыкли.