Вопросы и ответы по Amazon RDS

Служба реляционных баз данных Amazon (Amazon RDS) – это управляемый сервис, который упрощает настройку, использование и масштабирование реляционной базы данных в облаке. Этот сервис предоставляет экономичные масштабируемые ресурсы и одновременно управляет трудоемкими задачами администрирования баз данных. Благодаря этому пользователь может сосредоточиться на приложениях и ведении бизнеса.

Сервис Amazon RDS позволяет использовать привычные базы данных, такие как MySQL, MariaDB, Oracle, SQL Server или PostgreSQL. Поэтому код, приложения и инструменты, используемые при работе с существующими базами данных, будут эффективно интегрированы с сервисом Amazon RDS. Amazon RDS может автоматически создавать резервную копию базы данных и поддерживать ПО базы данных в актуальном состоянии путем обновления до последней версии. Благодаря гибкости сервиса можно без труда масштабировать вычислительные ресурсы и емкость хранилища, связанные с используемым инстансом реляционной БД. Кроме того, Amazon RDS упрощает процесс репликации, что повышает доступность БД и надежность хранения данных, а также обеспечивает масштабирование ресурсов для выполнения рабочих нагрузок с большим количеством операций чтения, снимая ограничения, которые накладывает использование одного инстанса БД. Как и при работе с другими сервисами Amazon Web Services, предварительные капиталовложения не требуются. Оплата начисляется только за используемые ресурсы.

Amazon Web Services предлагает разработчикам множество решений для баз данных. Сервис Amazon RDS позволяет запускать полностью управляемую реляционную базу данных с полным набором функций и обеспечивает администрирование БД. Используя один из множества доступных AMI реляционных баз данных в Amazon EC2, можно самостоятельно управлять реляционной базой данных в облаке. Данные решения обладают важными различиями и предназначены для разных примеров использования. Рекомендации по выбору подходящего решения см. на странице Облачные базы данных на AWS.

Да, Amazon RDS может работать локально с помощью Amazon RDS on Outposts. Подробнее см. в разделах вопросов и ответов по Amazon RDS on Outposts.

Да, специалисты Amazon RDS готовы ответить на вопросы и обеспечить поддержку. Напишите нам, и мы свяжемся с вами в течение одного рабочего дня, чтобы рассказать, как AWS может помочь вашей организации.

Вы можете установить соединение между вычислительным инстансом EC2 и новой базой данных Amazon RDS на консоли Amazon RDS. На странице Create database («Создать базу данных») выберите опцию Connect to an EC2 compute resource («Подключиться к вычислительному ресурсу EC2») в разделе Connectivity («Возможности подключения»). При выборе этой опции Amazon RDS автоматизирует задания ручной настройки сети, например создание VPC, групп безопасности, подсетей и правил передачи/приема для установления соединения между вашим приложением и базой данных.

Кроме того, можно установить соединение между существующей базой данных Amazon RDS и вычислительным инстансом EC2. Для этого откройте консоль RDS, найдите нужную базу данных на странице со списком баз данных и выберите Set up EC2 connection («Установить соединение с EC2») из выпадающего меню Action («Действие»). Amazon RDS автоматически настраивает соответствующие сетевые параметры для обеспечения безопасного соединения между выбранным инстансом EC2 и базой данных RDS.

Такое автоматическое соединение повышает производительность работы новых пользователей и разработчиков приложений. Теперь пользователи могут быстро и без проблем подключить приложение или клиента, использующего SQL на базе вычислительного инстанса EC2, к базе данных RDS в течение нескольких минут.

Инстанс БД представляет собой среду базы данных в облаке, вычислительные ресурсы и емкость хранилища которой определяет пользователь. Инстансы БД можно создавать и удалять, задавать или изменять атрибуты их инфраструктуры, а также управлять безопасностью и настройками доступа с помощью AWS Management Console, Amazon RDS APIs и AWS Command Line Interface. Можно запустить один или несколько инстансов БД, при этом каждый из них может поддерживать одну или несколько баз данных или схем БД в зависимости от типа ядра.

Инстансы БД можно быстро создать с помощью Консоли управления AWS, Amazon RDS APIs или AWS Command Line Interface. Чтобы запустить инстанс БД с помощью Консоли управления AWS, выберите RDS, а затем нажмите кнопку Launch DB Instance («Запустить инстанс БД»), расположенную на вкладке Instances («Инстансы»). Далее можно задать параметры для инстанса БД, включая ядро и версию БД, модель лицензирования, тип инстанса, тип и объем хранилища, а также данные для доступа основного пользователя.

Можно также изменять политику хранения резервных копий, предпочтительный интервал резервного копирования и запланированное окно обслуживания инстанса БД. Кроме того, инстансы БД можно создавать с помощью вызова API CreateDBInstance или команды create‑db‑instance.

После создания инстанса БД его адрес можно узнать в разделе с описанием инстанса БД в Консоли управления AWS, с помощью API DescribeDBInstances или команды describe‑db‑instances. С помощью этого адреса можно создать строку подключения, необходимую для непосредственного подключения к инстансу БД, используя предпочтительный инструмент для работы с БД или язык программирования. Чтобы разрешить сетевые запросы к работающему инстансу БД, необходимо авторизовать доступ. Подробнее о создании строки подключения и начале работы см. в Руководстве по началу работы.

По умолчанию пользователи могут создать до 40 инстансов БД Amazon RDS. Из этих 40 инстансов можно создать до 10 инстансов БД Oracle или SQL Server в рамках модели лицензирования «лицензия включена». Все 40 инстансов можно использовать для запуска БД Amazon Aurora, MySQL, MariaDB, PostgreSQL или Oracle по модели с поддержкой собственных лицензий (BYOL). Примечание. При использовании RDS для SQL Server действует ограничение: на одном инстансе БД нельзя запускать более 100 баз данных. Подробнее см. в Руководстве пользователя Amazon RDS для SQL Server.

• RDS для Amazon Aurora: ограничения, накладываемые ПО, отсутствуют.
• RDS для MySQL: ограничения, накладываемые ПО, отсутствуют.
• RDS для MariaDB: ограничения, накладываемые ПО, отсутствуют.
• RDS для Oracle: 1 база данных на инстанс; ограничения по количеству схем на одну БД, накладываемые ПО, отсутствуют.
• RDS для SQL Server: до 100 БД на инстанс.
• RDS для PostgreSQL: ограничения, накладываемые ПО, отсутствуют.

Существует несколько простых способов импорта данных в Amazon RDS: утилиты mysqldump или mysqlimport для MySQL; Data Pump, import/export или SQL Loader для Oracle; мастер импорта/экспорта, файлы полного резервного копирования (.bak) или Bulk Copy Program (BCP) для SQL Server; утилита pg_dump для PostgreSQL. Подробнее об импорте и экспорте данных см. в Руководстве по импорту данных для MySQL, Руководстве по импорту данных для Oracle, Руководстве по импорту данных для SQL Server или Руководстве по импорту данных для PostgreSQL.

Кроме того, просто и безопасно выполнить миграцию базы данных в AWS позволяет сервис AWS Database Migration Service.

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

События обслуживания, требующие отключения инстансов БД Amazon RDS, включают масштабирование вычислительных ресурсов (которое обычно занимает всего несколько минут), обновление версий ядра БД и установку необходимых исправлений ПО. Установка необходимых исправлений ПО планируется автоматически только для исправлений, связанных с безопасностью или надежностью данных. Установка исправлений требуется довольно редко (обычно один раз в несколько месяцев) и, как правило, занимает незначительную часть запланированного окна обслуживания.

Если предпочтительное еженедельное окно обслуживания не указывается при создании инстанса БД, ему присваивается значение по умолчанию, равное 30 минутам. Интервал обслуживания можно изменить, отредактировав инстанс БД в Консоли управления AWS с помощью ModifyDBInstance API или команды modify‑db‑instance. При необходимости для каждого из инстансов БД можно задать различные предпочтительные окна обслуживания.

Запуск инстанса БД с развертыванием в нескольких зонах доступности может дополнительно снизить влияние событий обслуживания. Подробнее о техническом обслуживании см. в Руководстве пользователя по Amazon RDS.

Для рабочих баз данных рекомендуется активировать функцию улучшенного мониторинга, что обеспечит доступ к более чем 50 метрикам ЦПУ, памяти, файловой системы и дисковых операций ввода-вывода. Эту возможность можно включить для каждого инстанса, и можно также выбрать степень детализации (вплоть до 1 секунды). Высокий уровень загрузки ЦПУ может снизить производительность запросов, и в этом случае может потребоваться масштабирование класса инстанса БД. Подробнее о мониторинге инстанса БД см. в Руководстве пользователя по Amazon RDS.

При использовании RDS для MySQL или MariaDB можно просмотреть журналы медленных запросов для конкретной БД, определить наличие медленно исполняемых SQL‑запросов и, если таковые существуют, ознакомиться с характеристиками производительности каждого из них. Чтобы просмотреть список медленно исполняемых SQL‑запросов, можно установить параметр БД slow_query_log и опросить таблицу mysql.slow_log. Подробнее см. в Руководстве пользователя по Amazon RDS.

При использовании RDS для Oracle для выявления медленных запросов можно использовать данные файла трассировки Oracle. Подробнее о получении доступа к данным файла трассировки см. в Руководстве пользователя по Amazon RDS. 

При использовании RDS для SQL Server для выявления медленных запросов можно использовать трассировку клиентской части SQL Server. Подробнее о получении доступа к данным файла трассировки серверной части см. в Руководстве пользователя по Amazon RDS.

Список поддерживаемых версий ядра базы данных см. в документации на каждое ядро БД:

• Amazon RDS for MySQL
• Amazon RDS for MariaDB
• Amazon RDS for PostgreSQL
  
• Amazon RDS for Oracle
  
• Amazon RDS for SQL Server
  
• Amazon Aurora

Подробнее об особенностях нумерации версий ядер см. на странице вопросов и ответов по каждому из ядер БД Amazon RDS.

• Amazon RDS для MySQL
• Amazon RDS for MariaDB
• Amazon RDS for PostgreSQL
• Amazon RDS for Oracle
• Amazon RDS for SQL Server
• Amazon Aurora
  

Amazon RDS постепенно добавляет поддержку новых версий БД, включая основные и второстепенные. Количество поддерживаемых новых версий может меняться в зависимости от частоты и содержимого выпусков и исправлений, публикуемых поставщиком или разрабатывающей организацией, и результатов подробных исследований этих выпусков и исправлений со стороны нашей технической службы БД. Как правило, мы стремимся внедрять поддержку новых версий ядер БД в течение 5 месяцев с момента их публикации в общем доступе.

Указать любую из поддерживаемых в настоящее время версий (второстепенную и основную) можно при создании нового инстанса БД с помощью операции Launch DB Instance («Запустить инстанс БД») в AWS Management Console или с помощью API CreateDBInstance. Обратите внимание, что в конкретном регионе AWS могут быть доступны не все версии ядер БД.

В Amazon RDS актуальное состояние инстансов БД обеспечивается благодаря предоставлению пользователям новых версий ядер поддерживаемых БД. После выпуска новой версии ядра БД поставщиком или разрабатывающей организацией это ядро тщательно тестируется нашей технической службой БД, прежде чем оно станет доступно в Amazon RDS.

Рекомендуется обновлять инстанс БД до самой последней второстепенной версии, поскольку она содержит последние исправления безопасности и функциональных возможностей. В отличие от обновлений основной версии, обновления второстепенной версии включают только изменения базы данных, которые имеют обратную совместимость с предыдущими второстепенными версиями той же основной версии ядра БД. 

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

Чтобы вручную обновить инстанс БД до поддерживаемой версии ядра, используйте команду Modify DB Instance в Консоли управления AWS или API ModifyDBInstance и установите параметр БД Engine Version в соответствии с нужной версией. По умолчанию обновления будут устанавливаться во время очередного окна обслуживания. Можно также осуществить немедленное обновление, выбрав параметр Apply Immediately в API консоли.

Если мы определим, что в новой второстепенной версии ядра содержатся значительные исправления ошибок по сравнению с ранее выпущенной второстепенной версией, будет запланировано автоматическое обновление инстансов БД, у которых параметр Auto Minor Version Upgrade имеет значение «Yes». Установка этих обновлений будет назначена на время запланированного пользователем окна обслуживания.

График обновлений составляется так, чтобы клиенты могли запланировать подходящее время, поскольку обновление версии ядра БД подразумевает период простоя, даже для инстансов, развертываемых в нескольких зонах доступности. Чтобы отключить автоматическое обновление второстепенных версий, установите значение «No» в поле Auto Minor Version Upgrade.

При использовании RDS для Oracle и RDS для SQL Server, если обновление до следующей второстепенной версии требует внесения изменений в другую редакцию, автоматическое обновление может не планироваться, даже при включенном параметре Auto Minor Version Upgrade. Решение о планировании автоматического обновления в таких ситуациях принимается индивидуально для каждого случая.

Так как обновление основных версий сопряжено с некоторым риском несовместимости, оно не выполняется автоматически и должно быть инициировано пользователем (за исключением описанного ниже случая, когда основная версия устарела). Подробнее об обновлении инстанса БД до новой версии ядра БД см. в Руководстве пользователя по Amazon RDS.

Да. Для этого следует создать снимок состояния БД существующего инстанса БД, создать новый инстанс БД путем восстановления из снимка состояния и инициировать для него обновление версии. После этого можно безопасно протестировать обновленную копию инстанса БД, чтобы принять решение об обновлении оригинального инстанса БД.

Подробнее о восстановлении снимка состояния БД см. в Руководстве пользователя по Amazon RDS.

• Поддерживать выпуски основных версий ядер (например, MySQL 5.6, PostgreSQL 9.6) планируется не менее трех лет с момента их первоначального появления в Amazon RDS.
• Поддерживать второстепенные версии ядер (например, MySQL 5.6.37, PostgreSQL 9.6.1) планируется не менее одного года с момента их первоначального появления в сервисе Amazon RDS.

Периодически придется прекращать поддержку отдельных основных или второстепенных версий ядер. Основные версии будут доступными, по крайней мере, до истечения периода действия соответствующей версии сообщества, либо пока для версии будут выпускаться исправления программного обеспечения или обновления безопасности. Для второстепенных версий это происходит, когда второстепенная версия имеет существенные ошибки или проблемы безопасности, которые были устранены в более позднем выпуске.

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

Если в Amazon RDS устарела второстепенная версия ядра БД, перед началом автоматического обновления предоставляется период времени в 3 (три) месяца с момента соответствующего объявления. По окончании этого периода для всех инстансов, работающих на устаревшей второстепенной версии, будет запланировано автоматическое обновление до последней поддерживаемой второстепенной версии на время окна обслуживания.

Когда в Amazon RDS устаревает основная версия ядра БД, предоставляется не менее 6 (шести) месяцев после объявления об устаревании, чтобы клиенты могли инициировать обновление до поддерживаемой основной версии. По окончании этого периода все инстансы, продолжающие работать с устаревшей версией, будут автоматически обновлены до следующей основной версии в рамках окна обслуживания.

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

В некоторых случаях мы можем завершить период поддержки определенных основных или дополнительных версий без предварительного уведомления, в частности, если мы обнаружим, что эта версия не соответствует нашим высоким стандартам качества, производительности или безопасности. Если подобные обстоятельства возникнут, что крайне маловероятно, Amazon RDS прекратит создание новых инстансов базы данных и кластеров с этими версиями. При этом существующие клиенты смогут продолжить работу с текущими базами данных. В зависимости от конкретных обстоятельств сроки решения рассматриваемой проблемы могут быть разными.

Вы платите только за то, чем пользуетесь, без минимальной оплаты или начальных взносов. Плата начисляется на основании следующих параметров.

• Часы использования инстанса БД – в зависимости от класса использованного инстанса БД (например, db.t2.micro, db.m4.large). Неполные использованные часы работы инстансов БД подлежат оплате на посекундной основе с минимальным платежом за 10 минут работы инстанса с момента изменения его статуса, приводящего к началу работы (т. е. с момента создания, запуска или изменения класса инстанса БД). Дополнительную информацию см. в наших новостях.
• Хранилище (за гигабайт в месяц) – объем хранилища, выделенного для инстанса БД. Если в течение месяца выполнялось масштабирование выделенных ресурсов хранилища, стоимость будет пересчитана пропорционально.
• Запросы на операции ввода‑вывода в месяц – общее количество выполненных в хранилище запросов на операции ввода‑вывода (только для хранилища на магнитном накопителе Amazon RDS и Amazon Aurora).
  
• Выделенное количество операций ввода‑вывода в секунду (IOPS) в месяц – выделенный объем IOPS, не зависящий от общего количества выполненных запросов на операции ввода‑вывода (только для хранилища с выделенным объемом IOPS (SSD) Amazon RDS).
• Хранилище резервных копий данных – хранилище для автоматических резервных копий БД и всех снимков состояния БД, созданных клиентом. Увеличение срока хранения резервных копий или создание дополнительных снимков состояния БД приводит к увеличению объема хранилища резервных копий, потребляемого базой данных.
  
• Передача данных – передача входящих и исходящих данных при обмене данными между инстансом БД и Интернетом.

Подробнее о ценах на Amazon RDS см. в разделе цен на странице сервиса Amazon RDS.

Плата за использование инстанса БД начисляется, пока инстанс БД доступен. Плата перестает начисляться после остановки работы инстанса, что может произойти в случае удаления инстанса либо при сбое в его работе.

При расчете оплачиваемых часов учитываются все инстансы БД, которые работают и доступны. Чтобы прекратить начисление платы за использование инстанса БД, необходимо остановить работу инстанса или удалить его. Неполные использованные часы работы инстансов БД подлежат оплате на посекундной основе с минимальным платежом за 10 минут работы инстанса с момента изменения его статуса, приводящего к началу работы (т. е. с момента создания, запуска или изменения класса инстанса БД).

Пока инстанс БД остановлен, плата начисляется за предоставленное хранилище (включая выделенные IOPS) и резервное хранилище (включая созданные вручную снимки состояния и автоматические резервные копии в указанный период хранения резервных копий), но не начисляется за часы работы инстанса БД.

Бесплатное хранилище резервных копий предоставляется на полный объем выделенного хранилища баз данных в вашем аккаунте в целом регионе. Например, если у вас есть инстанс БД MySQL со 100 ГБ выделенного хранилища на месяц и инстанс БД PostgreSQL со 150 ГБ выделенного хранилища на месяц и оба расположены в одном и том же регионе и принадлежат одному и тому же аккаунту, мы предоставим 250 ГБ хранилища резервных копий в данном аккаунте и регионе без дополнительной платы. Плата будет взиматься только за объем хранилища резервных копий сверх этой суммы.

Каждый день общий объем выделенного хранилища баз данных для вашего аккаунта в регионе сравнивается с общим объемом хранилища резервных копий в регионе и плата начисляется только на объем хранилища резервных копий, превышающий объем хранилища баз данных. Например, если превышение объема хранилища резервных копий составляет ежедневно ровно 10 ГБ, то плата будет начисляться за 10 ГБ-месяц хранилища резервных копий в месяц. Если объем выделенного хранилища составляет 300 ГБ в день, а хранилища резервных копий – 500 ГБ в день, но лишь в течение полумесяца, то с вас будет взиматься плата за 100 ГБ-месяц хранилища резервных копий (не за 200 ГБ-месяц), поскольку плата начисляется ежедневно (пропорционально) и резервные копии существуют не полный месяц. Заметьте, что бесплатное хранилище резервных копий является специфическим для аккаунта и региона.

Размер ваших резервных копий прямо пропорционален количеству данных на вашем инстансе. Например, если у вас есть инстанс БД со 100 ГБ выделенного хранилища, но храните на нем только 5 ГБ данных, то объем вашей первой резервной копии составит примерно 5 ГБ (не 100 ГБ). Следующие резервные копии являются инкрементальными: в них хранятся только измененные данные с инстанса БД. Отметьте, что размер хранилища резервных копий не отображается ни в консоли RDS, ни в ответе API DescribeDBSnapshots.

Хранилище, выделяемое инстансу БД для хранения первичных данных пользователя, находится в одной зоне доступности. При резервном копировании БД полученные резервные копии (вместе с журналами транзакций) реплицируются между несколькими зонами доступности, что обеспечивает геоизбыточность и еще большую надежность хранения данных. В стоимость дополнительного хранилища резервных копий (сверх того, что выделяется на бесплатной основе) входит эта дополнительная репликация, которая обеспечивает максимальную надежность хранения критически важных данных резервных копий.

Если указать, что инстанс БД необходимо развернуть в нескольких зонах доступности, оплата будет начисляться в соответствии с ценами на использование нескольких зон доступности, приведенными на странице цен на Amazon RDS. Плата за развертывание в нескольких зонах доступности начисляется на основании следующих параметров.

• Часы использования инстанса БД в нескольких зонах доступности в зависимости от класса использованного инстанса БД (например, db.t2.micro, db.m4.large). Как и при стандартных развертываниях в одной зоне доступности, неполные использованные часы работы инстансов БД подлежат оплате на посекундной основе с минимальным платежом за 10 минут работы инстанса с момента изменения его статуса, приводящего к началу работы (т. е. с момента создания, запуска или изменения класса инстанса БД). При смене типа развертывания инстанса БД (со стандартного на развертывание в нескольких зонах доступности или наоборот) в течение одного часа оплата за этот час будет начисляться согласно обоим тарифам.
• Выделенное хранилище (при развертывании инстанса БД в нескольких зонах доступности). При смене типа развертывания инстанса БД (со стандартного на развертывание в нескольких зонах доступности или наоборот) в течение одного часа оплата за этот час будет начисляться согласно большему из двух тарифов.
• Запросы на операции ввода‑вывода в месяц. Общее количество выполненных в хранилище запросов на операции ввода‑вывода. При развертывании инстанса БД в нескольких зонах доступности используется большее количество запросов на операции ввода‑вывода, чем при стандартном развертывании инстанса БД, которое зависит от соотношения числа операций чтения и записи в БД пользователя. С случае обновления БД объем операций ввода‑вывода при записи удваивается, так как сервис Amazon RDS синхронно реплицирует данные на резервный инстанс БД. Использование операций ввода‑вывода при чтении остается прежним.
• Хранилище резервных копий. Использование хранилища резервных копий не зависит от того, использовалось для инстанса БД стандартное развертывание или развертывание в нескольких зонах доступности. Резервные копии просто будут создаваться на резервном инстансе БД, что позволит избежать приостановки выполнения операций ввода‑вывода на основном инстансе БД.
• Передача данных. Плата за передачу данных при репликации данных между основным и резервным инстансом БД не взимается. Плата за передачу входящих и исходящих данных при обмене данными между инстансом БД и Интернетом начисляется так же, как при стандартном развертывании.

Если не указано иное, представленные здесь цены не включают применимые налоги и сборы, в том числе НДС и применимый налог с продаж. Для клиентов с платежным адресом в Японии использование сервисов AWS облагается потребительским налогом Японии. Подробнее.

Уровень бесплатного пользования AWS для Amazon RDS позволяет бесплатно использовать микроинстансы БД в одной зоне доступности под управлением MySQL, MariaDB, PostgreSQL, Oracle (с использованием собственной лицензии (BYOL)) и SQL Server Express Edition. Уровень бесплатного пользования включает 750 часов работы инстанса в месяц. Клиенты также ежемесячно получают бесплатно 20 ГБ на универсальных томах (SSD) для хранения баз данных и 20 ГБ для хранения резервных копий.

Новые аккаунты AWS получают доступ к уровню бесплатного пользования на 12 месяцев. Подробнее см. на странице Уровень бесплатного пользования AWS: вопросы и ответы.

Да. В рамках уровня бесплатного пользования AWS для Amazon RDS можно одновременно запускать более одного микроинстанса БД в одной зоне доступности. Однако суммарное превышение 750 часов использования всех микроинстансов БД в одной зоне доступности и для всех ядер БД и регионов будет оплачиваться по стандартным ценам на Amazon RDS.

Например, если запустить два микроинстанса БД в одной зоне доступности, при этом время работы каждого из них составит 400 часов в месяц, то суммарное время использования инстансов составит 800 часов, из которых 750 часов будут бесплатными. За оставшиеся 50 часов будет взиматься оплата по стандартным тарифам на Amazon RDS.

Нет. Клиент на уровне бесплатного пользования AWS может использовать до 750 часов работы любого из микроинстансов БД под управлением MySQL, PostgreSQL, Oracle или SQL Server Express Edition. Любое использование сверх 750 часов, определяемое в сумме для всех микроинстансов БД в одной зоне доступности и для всех ядер БД и регионов, будет оплачиваться по стандартным ценам на Amazon RDS.

Плата взимается согласно стандартным ценам на Amazon RDS за часы использования инстанса сверх часов, предоставленных в рамках уровня бесплатного пользования AWS. Подробнее см. на странице цен на Amazon RDS.

Зарезервированные инстансы Amazon RDS – это возможность зарезервировать инстанс БД на год или на три года и взамен получить значительную скидку по сравнению со стоимостью инстансов БД по требованию. Для зарезервированных инстансов существуют три варианта оплаты: без предоплаты, с частичной предоплатой и с полной предоплатой. Выбор подходящего варианта позволит добиться оптимального соотношения между авансовыми платежами и почасовой оплатой.

Функциональные возможности зарезервированных инстансов и инстансов БД по требованию абсолютно одинаковы. Единственное отличие состоит в способе начисления платы за использование инстансов БД. При использовании зарезервированных инстансов вы резервируете ресурсы сроком на один или три года и взамен получаете более низкий почасовой тариф (по сравнению с инстансами БД по требованию) на весь срок резервирования. Если зарезервированные инстансы в регионе не приобретены, все инстансы БД подлежат оплате на основании почасового тарифа как инстансы по требованию.

Приобрести зарезервированный инстанс можно в разделе Reserved Instance («Зарезервированные инстансы») в Консоли управления AWS для Amazon RDS. Можно также использовать API сервиса Amazon RDS или интерфейс командной строки AWS для получения списка доступных резервирований и последующей покупки зарезервированного инстанса БД.

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

Зарезервированные инстансы Amazon RDS приобретаются для региона, а не для конкретной зоны доступности. Поскольку зарезервированные инстансы не относятся к конкретной зоне доступности, ресурсы для них не резервируются. Это означает, что даже если в одной зоне доступности ресурсы ограничены, их можно будет приобрести в пределах региона, и скидка будет применяться для соответствующего использования в любой зоне доступности в этом регионе.

Можно приобрести до 40 зарезервированных инстансов БД. Если требуется запустить более 40 инстансов БД, заполните форму запроса инстансов БД Amazon RDS.

Просто приобретите зарезервированный инстанс БД с такими же параметрами (с таким же классом инстанса БД, ядром БД, вариантом развертывания, моделью лицензирования и в том же регионе), какие в данный момент используются на существующем инстансе БД, к которому требуется применить тариф с резервированием. Если зарезервированный инстанс был успешно приобретен, Amazon RDS автоматически применит пониженный почасовой тариф к существующему инстансу БД.

Изменение тарифов, связанное с зарезервированным инстансом, произойдет сразу после получения запроса и обработки платежа. За состоянием зарезервированных инстансов можно следить на странице истории аккаунта AWS или с помощью API DescribeReservedDBInstances. Если разовый платеж не удастся обработать к началу следующего расчетного периода, тариф со скидкой не будет применен.

По истечении срока резервирования за использование зарезервированного инстанса начнет взиматься почасовая плата как за инстанс по требованию, согласно классу инстанса БД и региону.

Операции Amazon RDS по созданию, изменению и удалению инстансов БД для зарезервированных инстансов и инстансов по требованию ничем не отличаются. При выставлении счета наша система автоматически учтет все резервирования, чтобы соответствующие зарезервированные инстансы БД оплачивались по сниженному почасовому тарифу.

Каждый зарезервированный инстанс связан со следующим набором атрибутов: ядром БД, классом инстанса БД, возможностью развертывания в нескольких зонах доступности, моделью лицензирования и регионом.

Резервирование для ядра БД и модели лицензирования, к которым применим гибкий подход к размеру инстанса (MySQL, MariaDB, PostgreSQL, Amazon Aurora или Oracle в рамках модели поддержки собственных лицензий), будет автоматически распространяться на запущенные инстансы БД любого размера в пределах соответствующего семейства инстансов (например, M4, T2 или R3), использующих то же ядро БД и находящихся в пределах того же региона. Помимо этого, резервирование будет применяться к инстансам БД, запущенным в режимах развертывания как в одной, так и в нескольких зонах доступности.

Для примера рассмотрим случай резервирования инстанса типа db.m4.2xlarge для ядра БД MySQL. В случае масштабирования запущенного инстанса БД до db.m4.4xlarge специальный тариф этого зарезервированного инстанса покроет половину стоимости использования более крупного инстанса БД.

Если ядро запущенной БД или ее модель лицензирования не подпадают под действие гибкого подхода к размеру инстанса (Microsoft SQL Server или Oracle в рамках модели «лицензия включена»), каждое резервирование в течение всего срока действия будет распространяться только на инстансы БД с полностью совпадающими атрибутами. При изменении любого из этих атрибутов работающего инстанса БД до окончания срока резервирования, вместо оплаты согласно почасовым тарифам за использование зарезервированного инстанса БД будет начисляться оплата согласно почасовым тарифам инстансов по требованию.

Подробнее о гибком подходе к размеру инстанса см. в Руководстве пользователя по Amazon RDS.

Каждый зарезервированный инстанс связан с определенным регионом. Эта связь сохраняется в течение всего срока резервирования, и ее нельзя изменить. Однако резервирование может использоваться в любой зоне доступности в пределах соответствующего региона.

Да. Приобретая зарезервированный инстанс, вы можете выбрать в конфигурации инстанса БД, доступного для покупки, вариант с развертыванием в нескольких зонах доступности. Кроме того, если вы используете движок БД и модель лицензии, обеспечивающие гибкость настройки на стороне зарезервированного инстанса, зарезервированный инстанс, развертываемый в нескольких зонах доступности, покроет стоимость использования двух инстансов БД, размещенных в одной зоне доступности.

Резервирование инстанса БД может применяться к реплике чтения при условии, что у них совпадают класс инстанса БД и регион. При выставлении счета наша система автоматически учтет все резервирования, чтобы соответствующие инстансы БД оплачивались по сниженному почасовому тарифу зарезервированных инстансов БД.

Нет, отменить резервирование инстанса БД нельзя, внесенный разовый платеж (если таковой взимался) не возвращается. Каждый час в течение срока действия зарезервированных инстансов БД подлежит оплате независимо от использования.

Если зарезервированный инстанс приобретается с полной предоплатой, его стоимость будет покрыта авансовым платежом. При выборе варианта «Без предоплаты» авансовые платежи не потребуются. Общая стоимость зарезервированного инстанса без авансового платежа будет распределена по выплатам за каждый час (вне зависимости от использования инстанса). Частичная предоплата сочетает в себе свойства планов без авансового платежа и вариантов с полной предоплатой. При данном сценарии потребуется небольшой авансовый платеж, а затем при каждой почасовой выплате будет дополнительно взиматься небольшая сумма (вне зависимости от использования инстанса).

Чтобы выбрать исходный класс инстанса БД и емкость хранилища, необходимо оценить потребности приложения в вычислительных ресурсах, объеме памяти и емкости хранилища. Информацию о доступных классах инстансов БД см. в Руководстве пользователя по Amazon RDS.

Масштабировать вычислительные ресурсы и емкость хранилища, выделенные для инстанса БД, можно с помощью Консоли управления AWS (выбрав нужный инстанс БД и нажав кнопку Modify («Изменить»)), API Amazon RDS или интерфейса командной строки AWS. Ресурсы памяти и ЦПУ можно масштабировать, изменив класс инстанса БД, а доступную емкость хранилища – изменив выделенную емкость хранилища. 

Обратите внимание, запрошенные изменения класса инстанса БД или выделенной емкости хранилища будут выполнены в рамках запланированного окна обслуживания. Кроме того, можно установить флаг apply‑immediately, чтобы запрос на масштабирование был исполнен сразу. Учтите, этот процесс также затронет другие системные изменения, ожидающие применения.

Некоторые более старые инстансы RDS для SQL Server могут не подходить для реализации масштабируемого хранилища. Дополнительные сведения см. в разделе RDS для SQL Server: вопросы и ответы.

Для хранения БД и журналов Amazon RDS использует тома EBS. В зависимости от запрошенной емкости хранилища Amazon RDS автоматически распределяет данные между несколькими томами EBS, обеспечивая повышение производительности IOPS. Для существующих инстансов БД MySQL и Oracle может наблюдаться некоторое ускорение операций ввода-вывода при масштабировании хранилища. Масштабирование ресурсов хранилища, выделенных для инстанса БД, можно выполнить с помощью Консоли управления AWS, API ModifyDBInstance или команды modify‑db‑instance.

Подробности см. на странице Storage for Amazon RDS.

Емкость хранилища, выделенную для инстанса БД, можно увеличивать, сохраняя доступность инстанса БД. Однако при масштабировании в сторону увеличения или уменьшения вычислительных ресурсов, доступных инстансу БД, в процессе изменения класса инстанса БД база данных будет недоступна. Период времени, в течение которого база данных будет недоступна, обычно составляет всего несколько минут, и эта операция производится в рамках окна обслуживания, заданного для инстанса БД, за исключением случаев, когда изменения необходимо применить сразу.

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

Универсальное хранилище (SSD) Amazon RDS подходит для широкого диапазона рабочих нагрузок БД с умеренными требованиями к количеству операций ввода-вывода. Благодаря минимальным значениям в 3 IOPS/ГБ и пиковым значениям до 3000 IOPS этот вариант хранилища обеспечивает предсказуемую производительность, соответствующую потребностям большинства приложений.

Хранилище с выделенным объемом IOPS сервиса Amazon RDS – это вариант хранения на базе накопителей SSD, предназначенный для обеспечения быстрой, предсказуемой и стабильной производительности операций ввода‑вывода. При использовании хранилища Amazon RDS с выделенным объемом IOPS при создании инстанса БД указываются требования к IOPS, и сервис Amazon RDS выделяет указанный объем IOPS на весь срок использования инстанса БД. Хранилища с выделенным объемом IOPS (SSD) сервиса Amazon RDS оптимизированы для рабочих нагрузок транзакционных (OLTP) баз данных с большим количеством операций ввода‑вывода. Подробнее см. в Руководстве пользователя по Amazon RDS.

Хранилища на магнитном накопителе сервиса Amazon RDS подходят для работы с небольшими базами данных с относительно редким доступом к информации. Хранилища на магнитном накопителе не рекомендуется применять для инстансов рабочих баз данных.

Тип выбираемого хранилища должен наилучшим образом соответствовать рабочим нагрузкам.

• Интенсивные рабочие нагрузки OLTP: хранилище Amazon RDS с выделенным объемом IOPS (SSD)
• Рабочие нагрузки БД с умеренными требованиями к количеству операций ввода‑вывода: универсальное хранилище (SSD) Amazon RDS

Значения IOPS, поддерживаемые сервисом Amazon RDS, зависят от ядра БД. Подробнее см. в Руководстве пользователя по Amazon RDS.

Сервис Amazon RDS предлагает два различных способа резервного копирования и восстановления инстансов БД: автоматическое создание резервных копий и снимки состояния БД.

Возможность автоматического резервного копирования Amazon RDS позволяет восстанавливать инстанс БД на определенный момент времени. Если для инстанса БД включено автоматическое резервное копирование, Amazon RDS будет ежедневно создавать полный снимок состояния данных (в рамках предпочтительного интервала резервного копирования) и сохранять журналы транзакций (при внесении обновлений в инстанс БД). При запуске восстановления на момент времени к наиболее близкой резервной копии применяются журналы транзакций для возврата инстанса БД к заданному моменту времени. 

Сервис Amazon RDS хранит резервные копии инстансов БД в течение ограниченного периода времени, указанного пользователем. Это время называется сроком хранения; по умолчанию его значение равно 7 дням, однако его можно увеличить до 35 дней. При выполнении восстановления на момент времени можно указать любую секунду в течение срока хранения, вплоть до последнего времени восстановления. Для выяснения последнего времени восстановления инстанса БД, которое обычно находится в пределах последних пяти минут, можно использовать API DescribeDBInstances. 

Кроме того, последнее время восстановления инстанса БД можно найти в Консоли управления AWS на вкладке Description («Описание») в нижней части Консоли.

Создание снимков состояния БД инициируется пользователем, что позволяет создавать резервные копии инстанса БД в известном состоянии с необходимой частотой, а затем восстанавливать их из этих состояний в любое время. Снимки состояния БД можно создать с помощью Консоли управления AWS, вызова API CreateDBSnapshot или команды create‑db‑snapshot. Они сохраняются до тех пор, пока не будут специально удалены.

Снимки состояния, которые сервис Amazon RDS создает в рамках автоматического резервного копирования, можно копировать (с помощью Консоли AWS или команды copy‑db‑snapshot ) или использовать для восстановления инстансов БД из снимков состояния. Их можно определить по значению параметра Snapshot Type, указанному как «automated». Кроме того, можно узнать время, в которое был создан снимок состояния, по информации в поле Snapshot Created Time («Время создания снимка»). 

Для автоматических снимков состояния время создания снимка состояния (в формате UTC) также содержится в его идентификаторе.

Обратите внимание, при выполнении операции восстановления на момент времени или из снимка состояния БД будет создан новый инстанс БД с новым адресом (при необходимости прежний инстанс БД можно удалить). Это позволяет пользователям создавать множество инстансов БД из одного снимка состояния БД или резервной копии на момент времени.

По умолчанию Amazon RDS активирует автоматическое резервное копирование инстанса БД со сроком хранения в 7 дней. Чтобы изменить срок хранения резервных копий, воспользуйтесь консолью RDS, API CreateDBInstance (при создании нового инстанса БД) или API ModifyDBInstance (для существующих инстансов). Эти методы можно использовать для изменения параметра RetentionPeriod на любое значение от 0 (автоматическое резервное копирование отключается) до необходимого количества дней, до 35. Установить значение 0 невозможно, если инстанс БД является источником реплик чтения. Подробнее об автоматическом резервном копировании см. в Руководстве пользователя по Amazon RDS.

Предпочтительный интервал резервного копирования – это задаваемый пользователем период времени, в течение которого выполняется резервное копирование инстанса БД. Сервис Amazon RDS использует эти периодически создаваемые резервные копии данных в сочетании с журналами транзакций для восстановления инстансов БД до состояния на любой момент времени в течение срока хранения копии, вплоть до LatestRestorableTime (обычно находящегося в пределах последних пяти минут). В течение интервала резервного копирования операции ввода‑вывода для хранилища могут быть на короткое время приостановлены, пока выполняется инициализация резервного копирования данных (обычно занимающая несколько секунд), могут также наблюдаться кратковременные периоды увеличения задержки. В случае развертывания БД в нескольких зонах доступности операции ввода‑вывода не приостанавливаются, так как резервные копии снимаются с резервного инстанса.

Снимки состояния БД и автоматические резервные копии Amazon RDS помещаются в хранилище S3.

Чтобы управлять сроком хранения автоматических резервных копий, используйте Консоль управления AWS , API ModifyDBInstance или команду modify‑db‑instance, изменяя параметр RetentionPeriod. Чтобы полностью отключить автоматическое резервное копирование, установите срок хранения, равным нулю (не рекомендуется). Управление снимками состояния БД, созданными пользователями, осуществляется в консоли Amazon RDS, в разделе Snapshots («Снимки»). Кроме того, можно просматривать список снимков состояния БД, созданных пользователями для конкретного инстанса БД, с помощью API DescribeDBSnapshots или команды describe‑db‑snapshots, и удалять снимки состояния с помощью API DeleteDBSnapshot или команды delete‑db‑snapshot.

Ситуация, когда количество автоматических снимков состояния БД на один или на два больше количества дней в сроке хранения, является нормальной. Один дополнительный автоматический снимок состояния сохраняется для того, чтобы обеспечить возможность восстановления на какой‑либо момент времени в рамках срока хранения.

Например, если интервал резервного копирования – один день, потребуется два автоматических снимка состояния для поддержки восстановления в какой‑либо момент в рамках предыдущих суток. Кроме того, в сервисе может отображаться дополнительный автоматический снимок состояния, так как новый снимок всегда создается до удаления старого.

Перед удалением инстанса БД можно создать финальный снимок состояния БД, тогда в дальнейшем этот снимок состояния БД можно будет использовать для восстановления удаленного инстанса БД. Сервис Amazon RDS сохраняет финальные снимки состояния БД, созданные пользователями, со всеми прочими снимками состояния БД, созданными вручную, после удаления инстанса БД. Подробнее о ценах на хранилище резервного копирования см. на странице цен.

Автоматические резервные копии удаляются при удалении инстанса БД. Только сделанные вручную снимки состояния БД сохраняются после удаления инстанса БД.

Amazon VPC позволяет создать среду виртуальной сети в частном изолированном разделе облака AWS, в котором можно полностью контролировать различные аспекты, такие как диапазоны частных IP‑адресов, подсети, таблицы маршрутизации и сетевые шлюзы. Amazon VPC дает возможность определять топологию виртуальной сети и настраивать ее конфигурацию, что очень напоминает работу с традиционной IP‑сетью в собственном центре обработки данных.

VPC может быть полезно, если требуется запустить публичное интернет‑приложение, а используемые серверы должны располагаться в закрытой частной подсети. Например, можно создать публичную подсеть с доступом к Интернету для веб‑серверов и расположить внутренние инстансы БД Amazon RDS в частной подсети без доступа к Интернету. Подробнее об Amazon VPC см. в Руководстве пользователя Amazon Virtual Private Cloud.

Если аккаунт AWS был создан до 04.12.2013, пользователю может быть доступна среда Amazon Elastic Compute Cloud (EC2)‑Classic для Amazon RDS. Основные функциональные возможности Amazon RDS для EC2‑Classic и EC2‑VPC не отличаются. Amazon RDS управляет резервным копированием, установкой исправлений ПО, автоматическим обнаружением сбоев, репликами чтения и восстановлением независимо от того, развернуты инстансы БД внутри VPC или за его пределами. Подробнее об отличиях между EC2‑Classic и EC2‑VPC см. в документации к EC2.

Группа подсетей БД – это набор подсетей, который можно назначить инстансам БД Amazon RDS в VPC. В каждой группе подсетей БД должна быть по меньшей мере одна подсеть для каждой зоны доступности в данном регионе. При создании инстанса БД в VPC необходимо выбрать группу подсетей БД. Amazon RDS в дальнейшем использует эту группу подсетей БД и предпочитаемую зону доступности для выбора подсети и IP‑адреса в этой подсети. Amazon RDS создает эластичный сетевой интерфейс и связывает его с инстансом БД с указанным IP‑адресом.

Обратите внимание, для подключения к инстансу БД настоятельно рекомендуется использовать имя DNS, поскольку основной IP‑адрес может меняться (например, при обработке отказа).

При развертывании в нескольких зонах доступности назначение подсети для всех зон доступности в регионе позволит Amazon RDS в случае необходимости создать новый резервный инстанс в другой зоне доступности. Рекомендуется сделать это даже при развертывании в одной зоне доступности просто на тот случай, если на каком‑то этапе необходимо будет преобразовать развертывание в одной зоне доступности в развертывание в нескольких зонах доступности.

Поэтапное руководство по данному процессу см. в разделе Создание инстанса БД в VPC Руководстве пользователя по Amazon RDS.

Изучите раздел Группы безопасности Руководства пользователя по Amazon RDS, чтобы узнать о различных способах управления доступом к инстансам БД.

К инстансам БД, развернутым в VPC, можно получить доступ из инстансов EC2, развернутых в том же VPC. Если эти инстансы EC2 были развернуты в публичной подсети с соответствующими эластичными IP‑адресами, можно получить доступ к инстансам EC2 через Интернет. К инстансам БД, развернутым в VPC, можно получить доступ из Интернета или из инстансов EC2, развернутых за пределами этого VPC, с помощью VPN или узлов‑бастионов, которые можно запускать в публичной подсети пользователя, или с помощью параметра публичного доступа Publicly Accessible в Amazon RDS.

• Чтобы использовать узел‑бастион, необходимо создать публичную подсеть с инстансом EC2, который будет действовать как SSH‑бастион. Для данной публичной подсети должны быть настроены интернет‑шлюз и правила маршрутизации, позволяющие перенаправить трафик через SSH‑узел, который должен затем пересылать запросы далее, на частный IP‑адрес инстанса БД Amazon RDS.
• Чтобы использовать подключение к общедоступным сетям, просто создайте инстансы БД, указав значение «yes» для параметра Publicly Accessible. С включенным параметром Publicly Accessible инстансы БД в VPC по умолчанию будут полностью доступны за пределами VPC. Это означает, что не потребуется настраивать VPN или узел‑бастион, чтобы разрешить доступ к инстансам.

Можно также настроить VPN‑шлюз, который расширит корпоративную сеть в облако VPC и обеспечит доступ к инстансу БД Amazon RDS в этом VPC. Подробнее см. в Руководстве пользователя Amazon VPC.

Настоятельно рекомендуется использовать имя DNS для подключения к инстансу БД, поскольку основной IP‑адрес может меняться (например, при обработке отказа).

Если инстанс БД находится не в VPC, с помощью Консоли управления AWS можно без труда переместить его в VPC. Подробнее см. в Руководстве пользователя Amazon RDS. Можно также сделать снимок инстанса БД за пределами VPC и восстановить его в VPC, указав группу подсети БД, которую необходимо использовать. Кроме того, можно воспользоваться командой восстановления на момент времени.

В настоящее время миграция инстансов БД из VPC за пределы VPC не поддерживается. В целях обеспечения безопасности снимок состояния инстанса БД, сделанный в VPC, нельзя восстанавливать за пределами VPC. То же самое касается возможности восстановления на момент времени. 

Пользователь отвечает за изменение таблиц маршрутизации и списков контроля доступа к сети в своем VPC, что обеспечивает доступность его инстансов БД для клиентских инстансов в VPC. При развертывании в нескольких зонах доступности после обработки отказа клиентский инстанс EC2 и инстанс БД Amazon RDS могут оказаться в разных зонах доступности. Необходимо настроить списки контроля доступа к сети, чтобы обеспечить возможность связи между различными зонами доступности.

Существующую группу подсети БД можно обновлять для добавления дополнительных подсетей как для существующих зон доступности, так и для новых зон доступности, добавленных с момента создания инстанса БД. Удаление подсетей из существующей группы подсетей БД может привести к недоступности инстансов, если они работают в определенной зоне доступности, которая была удалена из группы подсетей. Подробнее см. в Руководстве пользователя Amazon RDS.

Для начала работы с сервисом Amazon RDS необходим аккаунт разработчика AWS. При его отсутствии будет предложено создать его при регистрации в сервисе Amazon RDS. Аккаунт основного пользователя отличается от аккаунта разработчика AWS и используется в Amazon RDS только для управления доступом к инстансам БД. Аккаунт основного пользователя является внутренним аккаунтом пользователя БД, который можно использовать для подключения к инстансу БД. 

Можно указать имя основного пользователя и пароль, которые необходимо связать с каждым инстансом БД, при создании этого инстанса БД. После создания инстанса БД можно будет подключиться к базе данных с помощью учетных данных основного пользователя. Впоследствии можно создать дополнительные аккаунты пользователей, чтобы указать тех, кто может получать доступ к инстансу БД.

В MySQL основному пользователю по умолчанию предоставляются следующие права: create, drop, references, event, alter, delete, index, insert, select, update, create temporary tables, lock tables, trigger, create view, show view, alter routine, create routine, execute, trigger, create user, process, show databases, grant option.

В Oracle основному пользователю присваивается роль dba. Основной пользователь наследует большинство прав, связанных с ролью. Список запрещенных прав и соответствующих альтернативных вариантов выполнения задач администрирования, при выполнении которых могут потребоваться эти права, см. в Руководстве пользователя Amazon RDS.

В SQL Server пользователю, который создает базу данных, присваивается роль db_owner. Список запрещенных прав и соответствующих альтернативных вариантов выполнения задач администрирования, при выполнении которых могут потребоваться эти права, см. в Руководстве пользователя Amazon RDS.

Нет, все работает точно так же, как и в случае с реляционной базой данных, управляемой пользователем самостоятельно.

Да. Необходимо специально разрешить доступ к базе данных через Интернет путем соответствующей настройки групп безопасности. Можно разрешить доступ только с определенных IP‑адресов, диапазонов IP‑адресов или подсетей, соответствующих серверам в собственном ЦОД.

Да, все движки Amazon RDS поддерживают эту функцию. Amazon RDS генерирует сертификат SSL/TLS для каждого инстанса БД. После того как будет установлено зашифрованное соединение, данные, передаваемые между инстансом БД и приложением, будут шифроваться при передаче.

Хотя SSL обеспечивает безопасность, необходимо учитывать, что SSL/TLS‑шифрование является довольно ресурсоемкой операцией, которая приводит к увеличению задержек при соединении с базой данных. Поддержка SSL/TLS в Amazon RDS предназначена для шифрования соединения между приложением и инстансом БД; этого недостаточно для аутентификации доступа к самому инстансу БД.

Подробнее о создании зашифрованного соединения с Amazon RDS см. в следующей документации Amazon RDS: Руководство пользователя MySQL, Руководство пользователя MariaDB, Руководство пользователя PostgreSQL или Руководство пользователя Oracle. Подробнее о том, как SSL/TLS работает с этими ядрами БД, можно узнать непосредственно из документации MySQL, документации MariaDB, документации MSDN SQL Server, документации PostgreSQL или документации Oracle.

Amazon RDS поддерживает шифрование данных в состоянии покоя для всех ядер БД с использованием ключей, управляемых посредством сервиса AWS Key Management Service (KMS). В инстансе БД с шифрованием Amazon RDS шифруются все данные, находящиеся в базовом хранилище, а также автоматические резервные копии, реплики чтения и снимки состояния. Шифрование и дешифрование осуществляется по ходу работы. Подробнее об использовании KMS с Amazon RDS см. в Руководстве пользователя по Amazon RDS.

Можно также включить шифрование на ранее незашифрованном инстансе БД или кластере БД с помощью создания снимка состояния БД и затем копирования этого снимка состояния с указанием ключа шифрования KMS. После этого можно восстановить зашифрованный инстанс БД или кластер БД из зашифрованного снимка состояния.

Amazon RDS for Oracle и SQL Server поддерживает технологию прозрачного шифрования данных (TDE), которую используют эти системы. Подробнее см. в разделах Руководства пользователя по Amazon RDS, посвященных Oracle и SQL Server.

Вы можете контролировать действия, которые пользователи и группы AWS IAM могут выполнять над ресурсами Amazon RDS. Контроль производится посредством ссылок на ресурсы Amazon RDS в политиках AWS IAM, применяемым к пользователям и группам. К ресурсам Amazon RDS, на которые можно ссылаться в политике AWS IAM, относятся: инстансы БД, снимки состояния БД, реплики чтения, группы безопасности БД, группы настроек БД, группы параметров БД, подписки на события и группы подсетей БД. 

Кроме того, можно пометить эти ресурсы с помощью тегов, добавив дополнительные метаданные для ресурсов. С помощью тегов можно разделять ресурсы на категории (например, инстансы БД «Разработка», инстансы БД «Производство» и инстансы БД «Тестирование»), а также создавать политики AWS IAM со списком разрешений, т. е. действий, которые можно выполнять над ресурсами с одинаковыми тегами. Дополнительную информацию см. в разделе Использование тегов для ресурсов Amazon RDS.

Да. AWS CloudTrail – это веб‑сервис, который записывает вызовы AWS API для вашего аккаунта и предоставляет файлы журналов. История вызовов API AWS в CloudTrail позволяет проводить анализ безопасности и аудит соответствия требованиям, а также отслеживать изменения ресурсов.

Ответ. Да, все ядра БД в Amazon RDS соответствуют требованиям HIPAA, поэтому можно заключить с AWS договор делового партнерства (BAA) и использовать их для создания приложений, соответствующих требованиям HIPAA, и хранения информации, связанной со здравоохранением, в том числе закрытой медицинской информации (PHI).

Если договор BAA уже подписан, можно сразу начать использовать эти сервисы в аккаунтах, подпадающих под действие BAA. Если договор BAA с AWS еще не заключен или у вас есть вопросы о приложениях на AWS, соответствующих требованиям HIPAA, свяжитесь со своим персональным менеджером.

По умолчанию Amazon RDS выбирает оптимальные параметры конфигурации для инстансов БД, принимая во внимание класс инстанса и объем хранилища. Тем не менее при желании можно изменить их с помощью Консоли управления AWS, API сервиса Amazon RDS или интерфейса командной строки AWS. Следует помнить, что изменение рекомендованных параметров конфигурации может повлечь за собой нежелательные последствия, такие как снижение производительности или сбои системы. Поэтому к подобным мерам следует прибегать только продвинутым пользователям, которые осознают данные риски.

Группа параметров БД работает в качестве «контейнера» для параметров настройки ядра, которые могут применяться к одному или нескольким инстансам БД. При создании инстанса БД без указания группы параметров БД, используется группа по умолчанию. В этой группе содержатся параметры работы ядра и системы Amazon RDS, по умолчанию применяемые для используемого инстанса БД.

Чтобы задать пользовательские параметры работы для ядра инстанса БД, нужно просто создать новую группу параметров БД, изменить необходимые значения, а также настроить текущий инстанс БД таким образом, чтобы он использовал новую группу параметров. Значения параметров автоматически обновляются на всех инстансах БД, связанных с данной группой параметров БД.

Подробнее о настройке групп параметров БД см. в Руководстве пользователя по Amazon RDS.

Можно использовать сервис AWS Config для непрерывной записи изменений конфигурации инстансов БД Amazon RDS, групп подсетей БД, снимков состояния БД, групп безопасности БД и подписок на события, а также получать оповещения об изменениях с помощью сервиса Amazon Simple Notification Service (SNS). Можно также создать правила AWS Config, чтобы оценить, имеют ли ресурсы Amazon RDS требуемую конфигурацию.

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

Во время планового обслуживания некоторых типов или в маловероятном случае сбоя инстанса БД или всей зоны доступности Amazon RDS автоматически выполняет обработку отказа и переключение на резервную реплику, поэтому выполнение операций записи и чтения БД будет сразу же возобновлено. Адрес инстанса БД в процессе не меняется, поэтому приложение сможет продолжить работу с базой данных без дополнительной ручной настройки. Репликация при развертывании в нескольких зонах доступности осуществляется незаметно. Пользователь не выполняет никаких действий непосредственно с резервной репликой, ее нельзя использовать для распределения трафика операций чтения. Подробнее о развертывании в нескольких зонах доступности см. в Руководстве пользователя Amazon RDS.

Зоны доступности – это отдельные местоположения внутри региона, в силу особенностей конфигурации защищенные от влияния сбоев в других зонах доступности. Каждая зона доступности выполняется в собственной, физически изолированной, независимой инфраструктуре и изначально обладает высокой надежностью. Стандартные точки отказа (например, генераторы и оборудование для охлаждения) не используются совместно различными зонами доступности. Кроме того, зоны доступности физически отделены друг от друга, благодаря чему даже самые редкие стихийные бедствия (например, пожары, торнадо или наводнения) затронут только одну зону доступности. Между зонами доступности в одном и том же регионе работает сетевое подключение с низкой задержкой.

Основной инстанс БД, работающий в нескольких зонах доступности, обслуживает операции записи и чтения БД. Кроме него, Amazon RDS автоматически создает и поддерживает резервные инстансы, представляющие собой актуальные реплики основного инстанса. Резервные инстансы задействуются при выполнении сценария обработки сбоя. После обработки сбоя резервный инстанс становится основным и выполняет операции с базой данных. Ни на одном этапе использования резервного инстанса (т. е. предоставления ресурсов для выполнения операций чтения) пользователь не работает с ним напрямую. Подробнее о масштабировании операций чтения за пределы ресурсов отдельного инстанса БД см. в разделе вопросов и ответов о репликах чтения.

Основные преимущества запуска инстанса БД с развертыванием в нескольких зонах доступности – это повышение отказоустойчивости и доступности базы данных. Повышенная доступность и отказоустойчивость делают развертывание в нескольких зонах доступности оптимальным решением для использования в рабочей среде.

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

Запуск инстанса с развертыванием в нескольких зонах доступности также обеспечивает повышенную доступность базы данных. Если произойдет сбой зоны доступности или инстанса БД, база данных будет недоступна только во время автоматической обработки отказа. Развертывание в нескольких зонах доступности обеспечивает непрерывную работу в периоды планового обслуживания.
Например, при автоматическом резервном копировании выполнение операций ввода‑вывода на основном инстансе в рамках заданного интервала резервного копирования не приостанавливается, поскольку резервные копии делаются с резервного инстанса. При установке обновлений безопасности или масштабировании класса инстансов БД эти операции сначала выполняются для резервных инстансов перед автоматической обработкой отказа. Благодаря этому период недоступности БД сокращается до времени, требуемого на автоматическую обработку отказа.

Еще одно преимущество запуска инстанса БД в нескольких зонах доступности состоит в том, что обработка отказа инстанса БД осуществляется автоматически, без участия администратора. При использовании Amazon RDS не требуется отслеживать события инстанса БД и вручную инициировать восстановление инстанса БД (с помощью API RestoreDBInstanceToPointInTime или RestoreDBInstanceFromSnapshot) в случае сбоя последнего или всей зоны доступности.

В связи с синхронной репликацией данных может наблюдаться увеличение задержки по сравнению со стандартным развертыванием инстанса БД в одной зоне доступности.

Нет, резервный инстанс, развертываемый в нескольких зонах доступности, не предназначен для обслуживания запросов чтения. Развертывание в нескольких зонах доступности предназначено для повышения доступности и отказоустойчивости базы данных, а не для масштабирования операций чтения. При этом осуществляется синхронная репликация между основным и резервным инстансами. Реализация этого процесса гарантирует постоянную синхронизацию основной и резервной реплик, но препятствует обслуживанию операций чтения или записи с помощью резервной реплики. Если вас интересует решение по масштабированию операций чтения, ознакомьтесь с разделом вопросов и ответов о репликах чтения.

Для развертывания инстанса БД в нескольких зонах доступности при его запуске в Консоли управления AWS выберите «Yes» для параметра Multi‑AZ Deployment.

Либо выполните вызов CreateDBInstance в API сервиса Amazon RDS и установите значение «true» для параметра Multi‑AZ. Чтобы преобразовать существующий стандартный (в одной зоне доступности) инстанс БД для работы в нескольких зонах доступности, измените инстанс БД в Консоли управления AWS или с помощью API ModifyDBInstance, установив значение «true» для параметра Multi‑AZ.

В случае RDS для ядер БД MySQL, MariaDB, PostgreSQL и Oracle при конвертации инстанса Amazon RDS, развернутого в одной зоне доступности, в инстанс, развернутый в нескольких зонах доступности, происходит следующее.

• Делается снимок состояния основного инстанса.
• На основе снимка состояния в другой зоне доступности создается новый резервный инстанс.
• Настраивается синхронная репликация между основным и резервным инстансами.

Соответственно, во время конвертации инстанса, развернутого в одной зоне доступности, в инстанс, развернутый в нескольких зонах доступности, простоя в работе не происходит. Может, однако, наблюдаться некоторая задержка в те моменты, когда данные резервного инстанса синхронизируются с данными основного инстанса.

Amazon RDS определяет самые распространенные сценарии отказа и выполняет автоматическое восстановление, возобновляя работу базы данных в кратчайшие сроки и без вмешательства администратора. Amazon RDS выполняет автоматическую обработку отказа при любом из следующих условий:

• Потеря доступа в первичной зоне доступности
• Потеря сетевого подключения к основному инстансу
• Сбой вычислительного блока основного инстанса
• Сбой хранилища основного инстанса

Примечание. Когда в отношении инстансов, развернутых в нескольких зонах доступности, инициируются такие операции, как масштабирование инстанса БД или применение исправлений к ОС, в целях повышения доступности они применяются сначала к резервным репликам перед выполнением автоматической обработки отказа. В результате период недоступности сокращается до времени, требуемого на выполнение автоматической обработки отказа. Обратите внимание, что при развертывании в нескольких зонах доступности в Amazon RDS не предусмотрена автоматическая обработка отказа при таких операциях с базами данных, как длительно выполняющиеся запросы, взаимоблокировка или повреждения самой базы данных.

Да, Amazon RDS создает событие инстанса БД для оповещения о выполнении автоматической обработки отказа. Для получения информации о событиях, связанных с инстансом БД, щелкните по разделу «Events» в консоли Amazon RDS или используйте вызов API DescribeEvents. Можно также использовать оповещения о событиях Amazon RDS для получения оповещений об определенных событиях, произошедших в БД.

Обработка отказа выполняется сервисом Amazon RDS автоматически, поэтому работа с БД возобновляется очень быстро и не требует вмешательства администратора. При выполнении обработки отказа Amazon RDS изменяет запись канонического имени (CNAME) для инстанса БД таким образом, чтобы она указывала на резервную реплику, которая становится основной. Рекомендуется выполнить повторную попытку подключения к базе данных на уровне приложения.

Время обработки отказа, определяемое как интервал между обнаружением сбоя в основной реплике и возобновлением транзакций в резервной, обычно составляет от одной до двух минут. Время обработки отказа может зависеть от необходимости восстановления больших независимых транзакций. Для повышения эффективности в этом случае рекомендуется использовать типы инстансов соответствующего размера. AWS также рекомендует использовать с инстансами, работающими в нескольких зонах доступности, хранилища с выделенным объемом IOPS, что обеспечит быструю, прогнозируемую и стабильную передачу данных.

При возникновении различных состояний отказа Amazon RDS автоматически выполняет обработку отказа, не требующую вмешательства администратора. Кроме того, Amazon RDS позволяет инициировать обработку отказа при перезагрузке инстанса. Это можно сделать с помощью Консоли управления AWS или вызова API RebootDBInstance.

Для этого достаточно установить значение «true» для параметра Multi‑AZ. Создание резервных реплик, синхронная репликация и обработка отказа выполняются автоматически. Таким образом, нельзя выбрать зону доступности, в которой будет развернута резервная реплика, или задать число доступных резервных реплик. Amazon RDS выделяет одну резервную реплику на одну основную реплику инстанса БД. Резервную реплику также нельзя настроить для обслуживания операций чтения БД. Подробнее о развертывании в нескольких зонах доступности.

Да. Резервная реплика автоматически создается в другой зоне доступности того же региона, в котором находится основная реплика инстанса БД.

Да, увидеть местоположение текущей основной реплики можно в Консоли управления AWS или с помощью API DescribeDBInstances.

Зоны доступности спроектированы с учетом обеспечения низкой задержки сетевого подключения к другим зонам доступности того же самого региона. Кроме того, в архитектуре приложения и других ресурсов AWS может потребоваться предусмотреть избыточное копирование в несколько зон доступности, чтобы обеспечить отказоустойчивость приложения в случае сбоя одной из зон доступности. Это выполняется на уровне баз данных благодаря развертыванию в нескольких зонах доступности и не требует ручного администрирования.

Как при стандартном развертывании в одной зоне доступности, так и при развертывании в нескольких зонах доступности автоматическое резервное копирование и работа со снимками состояния БД выполняются одинаково. При запуске развертывания в нескольких зонах доступности система автоматически делает резервные копии и снимки состояния БД резервной реплики, чтобы не приостанавливать выполнение операций ввода‑вывода на основной. Обратите внимание, что во время резервного копирования в обоих типах развертываний может увеличиваться задержка при операциях ввода‑вывода (как правило, до нескольких минут).

Восстановление (на момент времени или из снимка состояния БД) при развертывании в нескольких зонах доступности выполняется точно так же, как и в стандартных развертываниях. Новые развертывания инстансов БД можно создавать с помощью вызовов API RestoreDBInstanceFromSnapshot или RestoreDBInstanceToPointInTime. Эти новые развертывания могут быть как стандартными, так и в нескольких зонах доступности, независимо от того, с какого развертывания была сделана резервная копия.

Реплики чтения упрощают использование функций репликации, которые встроены в поддерживаемые ядра, обеспечивая эластичное масштабирование ресурсов для выполнения рабочих нагрузок с большим количеством операций чтения и снимая ограничения, которые накладывает использование одного инстанса БД.

Реплику чтения можно создать за несколько щелчков кнопкой мыши с помощью Консоли управления AWS или API CreateDBInstanceReadReplica. После создания реплики чтения обновления базы данных в исходном инстансе БД реплицируются с использованием собственной системы асинхронной репликации данного ядра. Можно создать множество реплик чтения для одного исходного инстанса БД и распределить между ними трафик операций чтения, выполняемых приложением.

Поскольку используются функции репликации, встроенные в ядро, функционирование реплик чтения зависит от мощности и ограничений последнего. В частности, реплики чтения обновляются только после обновления исходного инстанса БД, и задержка репликации может варьироваться в широких пределах. Реплики чтения можно использовать вместе с развертыванием в нескольких зонах доступности для использования преимуществ масштабирования ресурсов чтения совместно с возможностями, которые дает развертывание в нескольких зонах доступности, такими как повышение доступности БД для записи и более высокая надежность данных.

Развертывание одной и более реплик чтения для данного исходного инстанса БД может быть эффективным в различных сценариях. Ниже перечислены самые распространенные из них.

• Масштабирование вычислительных ресурсов или ресурсов ввода‑вывода для преодоления ограничений одного инстанса БД при выполнении рабочих нагрузок с большим количеством операций чтения. Избыточный трафик чтения можно направить на одну и более реплик чтения.
• Обслуживание трафика операций чтения, когда исходный инстанс БД недоступен. Если исходный инстанс БД не принимает запросы ввода‑вывода (например, в связи с приостановкой ввода‑вывода во время выполнения резервного копирования или запланированного обслуживания), трафик операций чтения можно перенаправить на реплики чтения. Следует учитывать, что в этом случае данные, которые содержит реплика чтения, могут оказаться устаревшими вследствие недоступности исходного инстанса БД.
• Бизнес‑отчеты или сценарии хранения данных. Можно настроить запросы бизнес‑отчетов для работы с репликой чтения, а не с основным рабочим инстансом БД.
  
• Реплику чтения можно использовать для аварийного восстановления исходного инстанса БД в том же или другом регионе AWS.
  

Да. Перед добавлением реплик чтения следует настроить автоматическое резервное копирование для исходного инстанса БД, задав отличный от нуля срок хранения резервных копий. Для работы реплик чтения резервное копирование должно быть включено.

Amazon Aurora: все кластеры БД.

Amazon RDS for MySQL: все инстансы БД поддерживают создание реплик чтения. Для работы реплик чтения на исходном инстансе БД все время должны быть активированы автоматические резервные копии. Автоматическое резервное копирование реплик поддерживается только для реплик чтения Amazon RDS на ядре MySQL версии 5.6 или новее и не поддерживается для версии 5.5.

Amazon RDS for PostgreSQL: создание реплик чтения поддерживается инстансами БД с PostgreSQL версии 9.3.5 или новее. Существующие инстансы PostgreSQL более ранних версий должны быть обновлены до версии 9.3.5, чтобы работать с репликами чтения Amazon RDS.

Amazon RDS for MariaDB: все инстансы БД поддерживают создание реплик чтения. Для работы реплик чтения на исходном инстансе БД все время должны быть активированы автоматические резервные копии.

Amazon RDS for Oracle: поддерживается для Oracle версии 12.1.0.2.v12 и выше, а также для всех версий 12.2 с моделью использования собственной лицензии в Oracle Database Enterprise Edition и лицензией на Active Data Guard.

Amazon RDS for SQL Server: реплики чтения поддерживаются для версии Enterprise Edition в конфигурации с несколькими зонами доступности (при условии, что в качестве базовой технологии реплицирования используются группы доступности Always On для SQL Server версий 2016 и 2017).

Реплику чтения можно создать за считаные минуты с помощью стандартного API CreateDBInstanceReadReplica или за несколько щелчков кнопкой мыши в Консоли управления AWS. При создании реплики ее можно определить как реплику чтения, указав для нее идентификатор SourceDBInstanceIdentifier. SourceDBInstanceIdentifier – это идентификатор исходного реплицируемого инстанса БД. Как и для стандартного инстанса БД, можно также задать зону доступности, класс инстанса БД и предпочтительное окно обслуживания. Версия ядра (например, PostgreSQL 9.3.5) и местонахождение хранилища реплики чтения наследуются от исходного инстанса БД. 

Когда инициируется создание реплики чтения, Amazon RDS делает снимок состояния исходного инстанса БД и начинает репликацию. В ходе создания снимка состояния может наблюдаться краткая приостановка выполнения операций ввода‑вывода в исходном инстансе БД. Операции ввода‑вывода приостанавливаются, как правило, не более чем на одну минуту и совсем не приостанавливаются, если исходный инстанс БД развернут в нескольких зонах доступности (так как в этом случае снимки состояния делаются с резервных реплик).

В ближайшее время Amazon RDS будет доработан таким образом, что в случае создания множества реплик чтения в течение 30 минут для них будет использоваться один и тот же исходный снимок состояния, что уменьшит влияние на выполнение операций ввода‑вывода (процесс синхронизации репликации для каждой реплики чтения начнется сразу же после ее создания).

Подключиться к реплике чтения можно таким же образом, как и к стандартному инстансу БД, используя API DescribeDBInstance или Консоль управления AWS для получения адресов реплик чтения. Порядок распределения трафика чтения по множеству реплик чтения определяется приложением.

Amazon RDS для MySQL, MariaDB и PostgreSQL позволяют создавать не более 15 реплик чтения для одного исходного инстанса БД. Amazon RDS для Oracle и SQL Server позволяют создавать не более 5 реплик чтения для одного исходного инстанса БД.

Да, Amazon RDS (за исключением RDS for SQL Server) поддерживает межрегиональные реплики чтения. Задержка, с которой данные становятся доступны в реплике чтения после их записи в исходный инстанс БД, зависит от задержки в сети между двумя регионами.

Нет. Функционирование реплик чтения в Amazon RDS for MySQL, MariaDB, PostgreSQL, Oracle и SQL Server обеспечивается за счет механизмов асинхронной репликации, встроенных в ядра этих БД. В Amazon Aurora используется другой (тоже асинхронный) механизм репликации.

Чтобы повысить доступность БД для операций записи и защитить недавние обновления БД от различного рода сбоев с помощью репликации, рекомендуется развернуть инстанс БД в нескольких зонах доступности. Что же касается реплик чтения Amazon RDS, они реализуются посредством функций асинхронной репликации, встроенных в сами ядра. Запись в БД реплики чтения производится только после записи в БД исходного инстанса БД, и задержка репликации может варьироваться в широких пределах. 

Напротив, при развертывании в нескольких зонах доступности используется синхронная репликация, т. е. все операции записи в БД основной и резервной реплики выполняются одновременно. Это обеспечивает защиту последних обновлений БД, так как они будут доступны в резервной реплике, если потребуется выполнить обработку отказа. 

Кроме того, управление репликами при развертывании в нескольких зонах доступности полностью автоматизировано. Amazon RDS автоматически отслеживает состояние инстанса БД или зоны доступности и в случае отказа инициирует автоматическое переключение на резервный инстанс (или на реплику чтения в случае Amazon Aurora).

Да. Поскольку у инстансов БД, работающих в нескольких зонах доступности, и у реплик чтения различное назначение, целесообразно совместно использовать их при развертываниях в рабочей среде и связывать реплику чтения с инстансом БД, работающим в нескольких зонах доступности. При этом «исходный» инстанс БД, развернутый в нескольких зонах доступности, повысит доступность БД для операций записи и повысит сохранность данных, а связанная с ним реплика чтения повысит масштабируемость трафика операций чтения.

Да. Amazon RDS for MySQL, MariaDB, PostgreSQL и Oracle позволяет использовать для реплик чтения конфигурацию с несколькими зонами доступности для поддержки аварийного восстановления и сокращения простоев при обновлении ядра БД.

В случае обработки отказа при развертывании в нескольких зонах доступности репликация для всех связанных и доступных реплик чтения автоматически возобновится сразу же по завершении операции обработки отказа (с получением обновлений от реплик, ставших основными).

Amazon Aurora, Amazon RDS для MySQL и MariaDB: можно создать три уровня реплик чтения. Реплики чтения второго уровня из имеющейся реплики чтения первого уровня и реплика третьего уровня и реплик чтения второго уровня. Создав реплику чтения второго и третьего уровня, можно перенести часть нагрузки репликации с основного инстанса БД на разные уровни реплики чтения на основе ваших практических потребностей.

Обратите внимание, что реплика чтения второго уровня может значительно запаздывать по сравнению с основной в связи с появлением дополнительной задержки, возникающей при репликации транзакций с основного инстанса на реплику первого уровня, а с нее на реплику второго уровня. Аналогичным образом реплика третьего уровня может отставать от реплики чтения второго уровня.

Amazon RDS для Oracle и Amazon RDS для SQL Server: реплики чтения реплик чтения в настоящее время не поддерживаются.

Реплики чтения предназначены для обслуживания трафика операций чтения. Однако в некоторых случаях опытные пользователи могут выполнять операторы языка определения данных (DDL) SQL в отношении реплик чтения. Например, в реплику чтения можно добавить индекс БД для составления бизнес‑отчетов, не добавляя этот индекс в соответствующий исходный инстанс БД.

В Amazon RDS for MySQL можно путем настройки разрешить применение операторов DDL SQL к репликам чтения. Если для некоторой реплики чтения нужно разрешить другие операции, помимо чтения, измените для этой реплики чтения активную группу параметров БД, задав значение read_only равное нулю.

Amazon RDS for PostgreSQL в настоящее время не поддерживает выполнение операторов DDL SQL в отношении реплик чтения.

Да. Подробнее см. в Руководстве пользователя Amazon RDS.

Обновления исходного инстанса БД автоматически реплицируются во все связанные реплики чтения. Однако, в зависимости от поддерживаемой ядром технологии асинхронной репликации, обновления реплик чтения могут отставать от обновлений соответствующего исходного инстанса БД по ряду причин. Ниже перечислены наиболее частые причины такого отставания.

• объем операций ввода‑вывода при записи в исходный инстанс БД превышает скорость применения изменений к реплике чтения (чаще всего эта проблема возникает, когда объем вычислительных ресурсов исходного инстанса БД превышает объем вычислительных ресурсов реплики чтения);
• репликация в реплику чтения задерживается из‑за сложных или длительно выполняющихся транзакций в исходном инстансе БД;
• сетевое разграничение или задержка между исходным инстансом БД и репликой чтения.

Функционирование реплик чтения зависит от характеристик встроенной функции репликации поддерживаемых ядер. Используя реплики чтения, следует учитывать потенциальное время отставания реплики от ее исходного инстанса БД (так называемую противоречивость).

Для получения списка всех развернутых инстансов БД, включая реплики чтения, воспользуйтесь стандартным API DescribeDBInstances или перейдите на вкладку «Instances» в консоли Amazon RDS.

Amazon RDS позволяет увидеть, насколько реплика чтения отстает от своего исходного инстанса БД. Отставание (в секундах) публикуется в виде метрики Replica Lag в Amazon CloudWatch, доступной через Консоль управления AWS или с помощью API сервиса Amazon CloudWatch.

В Amazon RDS для MySQL эта информация поступает из того же источника, что и в случае применения к реплике чтения стандартной команды MySQL «Show Replica Status». В Amazon RDS for PostgreSQL для просмотра метрик репликации можно использовать представление pg_stat_replication для исходного инстанса БД.

Amazon RDS отслеживает состояние репликации созданных реплик чтения и меняет значение поля состояния репликации в Консоли управления AWS на Error, если репликация была остановлена по любым причинам (например, вследствие попыток запросов DML к реплике, конфликтующих с обновлениями основного инстанса БД, может возникнуть ошибка репликации). Подробности ошибки, выданной ядром MySQL, можно просмотреть, отобразив их в поле Replication Error, и предпринять соответствующие меры для устранения ее последствий. Подробнее о решении проблем репликации см. в разделе Troubleshooting a Read Replica Problem Руководства пользователя Amazon RDS для MySQL или PostgreSQL. 

Если ошибка репликации исправлена, в поле состояния репликации будет указано значение Replicating («Выполняется репликация»).

Чтобы репликация работала эффективно, рекомендуется предоставить для реплики чтения столько же вычислительных ресурсов и ресурсов хранилища, сколько имеется у соответствующих исходных инстансов БД, или даже больше. В противном случае есть вероятность увеличения отставания репликации или исчерпания пространства для хранения реплицированных обновлений.

Реплику чтения можно в несколько действий удалить в Консоли управления AWS или путем передачи идентификатора ее инстанса БД в DeleteDBInstance API. 

Реплика Amazon Aurora останется активной и продолжит прием трафика операций чтения даже после удаления соответствующего исходного инстанса БД. Одна из реплик в кластере будет автоматически назначена новой основной репликой и начнет принимать трафик операций записи.

Реплика чтения Amazon RDS для MySQL или MariaDB останется активной и продолжит прием трафика операций чтения даже после удаления соответствующего исходного инстанса БД. Если требуется удалить реплику чтения вместе с исходным инстансом БД, это следует сделать дополнительно с помощью API DeleteDBInstance или консоли управления AWS.

При удалении инстанса БД Amazon RDS for PostgreSQL, имеющего реплики чтения, последние станут самостоятельными инстансами БД и смогут принимать трафик операций чтения и записи. Эти новые инстансы БД будут работать независимо друг от друга. Если требуется удалить эти инстансы БД вместе с оригинальным исходным инстансом БД, это следует сделать дополнительно с помощью API DeleteDBInstance или Консоли управления AWS.

Плата за реплики чтения начисляется по той же схеме и тарифам, что и за стандартные инстансы БД. Как и для стандартного инстанса БД, почасовой тариф за инстанс БД для реплик чтения определяется классом инстанса БД реплики чтения. Актуальные цены приведены на странице цен. За передачу данных при выполнении репликации данных между исходным инстансом БД и репликой чтения в пределах одного региона AWS плата не взимается.

Начисление платы за использование реплики чтения начинается сразу после ее успешного создания (т. е. с момента, когда ее состояние отобразится как «активное»). Плата за использование реплики чтения будет начисляться по почасовым тарифам для стандартных инстансов БД Amazon RDS, пока вы не подадите команду для удаления этой реплики чтения.

Улучшенный мониторинг для Amazon RDS обеспечивает более полное представление о состоянии инстансов Amazon RDS. Просто включите опцию Enhanced Monitoring для инстанса БД Amazon RDS, задайте степень детализации – и функция улучшенного мониторинга будет собирать важные метрики операционной системы и данные о процессах с требуемой детализацией.

Для еще более подробной диагностики и визуализации нагрузки на базу данных и продления срока хранения данных можно воспользоваться компонентом Performance Insights.

При улучшенном мониторинге регистрируются метрики инстанса Amazon RDS на уровне системы, например метрики ЦПУ, памяти, файловой системы, дисковых операций ввода‑вывода и другие. Полный список метрик можно найти в документации.

Улучшенный мониторинг поддерживается для всех ядер БД Amazon RDS.

Улучшенный мониторинг поддерживается для всех типов инстансов, кроме t1.micro и m1.small. Режим улучшенного мониторинга использует некоторое количество ресурсов ЦПУ, памяти и операций ввода‑вывода, поэтому для целей стандартного мониторинга рекомендуется использовать высокую степень детализации только с инстансами размера medium и больше. Для непроизводственных инстансов БД по умолчанию улучшенный мониторинг выключен; можно оставить его выключенным или включить и настроить степень детализации.

В консоли можно в графическом формате посмотреть все системные метрики и данные о процессах для инстансов БД Amazon RDS. Можно управлять настройками для отслеживания определенного набора метрик для каждого инстанса, а также настроить панель управления в соответствии со своими потребностями.

Нет. Можно задать различную степень детализации для каждого инстанса БД в аккаунте Amazon RDS. Кроме того, можно выбрать, для каких инстансов будет работать режим улучшенного мониторинга, и изменять степень детализации для любого инстанса в любое время.

Можно просмотреть величины производительности для всех метрик за последний час с детализацией вплоть до 1 секунды в соответствии с настройками пользователя.

Метрики, создаваемые функцией улучшенного мониторинга Amazon RDS, записываются в журналы CloudWatch Logs аккаунта пользователя. Можно создавать в CloudWatch фильтры метрик, записанных в журналы CloudWatch Logs, и выводить их в графическом формате на панели управления CloudWatch. Подробнее см. на странице сервиса Amazon CloudWatch.

CloudWatch следует использовать, когда нужно просмотреть данные за прошедший период, недоступные в панели управления консоли Amazon RDS. Кроме того, в CloudWatch можно просматривать данные мониторинга инстансов Amazon RDS, что обеспечивает централизованный контроль состояния всего стека AWS. На данный момент CloudWatch поддерживает степень детализации до 1 минуты, при более высокой степени детализации значения усредняются.

Да. В CloudWatch можно создать предупреждение, которое отправит оповещение, когда предупреждение изменит состояние. Предупреждение отслеживает одну метрику в течение указанного пользователем периода и выполняет на протяжении этого периода одно или несколько действий по итогам сравнения значения метрики с указанным пороговым значением. Подробнее о создании предупреждений в CloudWatch см. в Руководстве разработчика по Amazon CloudWatch.

Улучшенный мониторинг Amazon RDS создает набор метрик в виде данных формата JSON, которые записываются в журналы CloudWatch вашего аккаунта. Данные в формате JSON представлены в соответствии со степенью детализации, заданной для конкретного инстанса Amazon RDS.

Существует два способа использовать эти метрики с помощью панели управления или приложения сторонних разработчиков. Инструменты мониторинга могут использовать подписку на журналы CloudWatch Logs для загрузки метрик в режиме, близком к реальному времени. Другой способ предполагает использование фильтров в журналах CloudWatch Logs для передачи всех необходимых метрик CloudWatch и интеграции приложения с CloudWatch. Подробности см. в документации Amazon CloudWatch.

Поскольку функция улучшенного мониторинга записывает данные в формате JSON в журналы CloudWatch Logs соответствующего аккаунта, пользователь может управлять сроком их хранения точно так же, как любыми другими потоковыми журналами, поступающими в CloudWatch Logs. По умолчанию срок хранения данных улучшенного мониторинга в журналах CloudWatch Logs составляет 30 дней. Подробнее о том, как изменить настройки времени хранения, см. в Руководстве разработчика по Amazon CloudWatch.

Поскольку созданные метрики импортируются в журналы CloudWatch Logs, то за передачу и хранение данных, использованные сверх уровня бесплатного пользования CloudWatch Logs, будет взиматься плата на основе тарифов сервиса CloudWatch. Сведения о ценах см. по ссылке. Объем информации, передаваемой для каждого инстанса Amazon RDS, прямо пропорционален заданной степени детализации улучшенного мониторинга. С целью управления затратами администраторы могут устанавливать для различных инстансов различную степень детализации.

Приблизительные объемы данных, импортируемых функцией улучшенного мониторинга в журналы CloudWatch Logs для одного инстанса, приведены ниже.

Прокси-сервер Amazon RDS – это полностью управляемый прокси-сервер с высоким уровнем доступности для Amazon RDS. RDS Proxy повышает масштабируемость приложений, их безопасность и устойчивость к сбоям баз данных.

Amazon RDS Proxy – это полностью управляемый и удобный прокси-сервер с высоким уровнем доступности для Amazon RDS, благодаря которому ваши приложения смогут: 1) повысить масштабируемость, организовывая пул подключений к базе данных и используя их совместно с другими приложениями; 2) повысить доступность, сокращая время обработки отказов баз данных почти на 66 %, сохраняя при этом подключения приложений; 3) повысить уровень безопасности путем принудительного применения аутентификации AWS IAM для баз данных и безопасного хранения данных для доступа в AWS Secrets Manager, когда это необходимо.

Amazon RDS Proxy поддерживает определенные примеры использования, связанные с масштабированием, доступностью и безопасностью приложений, в том числе указанные ниже.

Приложения с непредсказуемыми рабочими нагрузками. Приложения, которые поддерживают разносторонние рабочие нагрузки, могут пытаться открыть множество новых подключений к базе данных. Средства управления подключениями Amazon RDS Proxy дают возможность масштабировать приложения, которые работают с непредсказуемыми рабочими нагрузками, путем эффективного повторного использования подключений к базе данных. Сначала прокси-сервер RDS разрешает нескольким подключенным приложениям совместно использовать соединение с базой данных, чтобы эффективно использовать ее ресурсы. Затем RDS Proxy обеспечивает предсказуемую работу базы данных, управляя количеством открытых подключений к ней. В конце концов, RDS Proxy удаляет запросы, которые невозможно обслужить, чтобы общая производительность и доступность приложения оставалась неизменной.

Приложения, которые часто открывают и закрывают подключения к базе данных. Приложения, в основу которых положены такие технологии, как Serverless, PHP или Ruby on Rails, могут часто открывать и закрывать подключения к базе данных для обслуживания запросов. Amazon RDS Proxy создает пул подключений к базе данных во избежание излишней нагрузки на вычислительные мощности и память базы данных из-за установки новых подключений.

Приложения, которые сохраняют подключение, но не пользуются им. Приложения в таких отраслях, как SaaS или интернет-коммерция, могут сохранять подключение к базе данных в режиме простоя, чтобы сократить время отклика при возобновлении активности клиента. Вместо того чтобы выделять избыточные ресурсы баз данных для поддержания подключений, которые, в основном, простаивают, можно воспользоваться Amazon RDS Proxy, чтобы удерживать простаивающие подключения только в необходимом количестве для оптимального обслуживания активных запросов.

Приложения, которые требуют доступности при временных сбоях. Используя Amazon RDS Proxy, можно создавать приложения с повышенной отказоустойчивостью без необходимости в написании сложного кода для обработки сбоев. RDS Proxy автоматически направляет трафик к новому инстансу базы данных, сохраняя подключения со стороны приложений. Кроме того, RDS Proxy работает в обход кэша системы доменных имен (DNS), сокращая время отказа почти на 66 % при использовании баз данных Amazon RDS и Aurora в нескольких зонах доступности. При отказе базы данных время отклика приложения может увеличиться, что приведет к повтору транзакций.

Повышенный уровень безопасности и централизованное управление данными для доступа. С помощью Amazon RDS Proxy можно создавать приложения с высоким уровнем безопасности путем принудительного применения аутентификации на основе IAM для подключения к реляционным базам данных. Также RDS Proxy предоставляет возможность централизованного управления данными для доступа с использованием AWS Secrets Manager.

Время отклика на запрос или транзакцию при использовании Amazon RDS Proxy может повышаться в среднем на пять миллисекунд в зависимости от рабочей нагрузки. Если для приложения недопустима задержка в пять миллисекунд или ему не требуется управлять подключениями и использовать другие функции RDS Proxy, можно подключать его непосредственно к серверу базы данных.

Благодаря Amazon RDS Proxy можно изменить подход к созданию современных бессерверных приложений, которые пользуются преимуществами эффективности и простоты реляционных баз данных. Во-первых, с помощью RDS Proxy можно эффективно масштабировать бессерверные приложения, создавая пулы подключений к базам данных и повторно используя эти подключения. Во-вторых, с RDS Proxy больше не потребуется обрабатывать данные для доступа к базе данных в коде Lambda. Для аутентификации в RDS Proxy и базе данных можно воспользоваться ролью выполнения IAM, связанной с функцией Lambda. В-третьих, для раскрытия всего потенциала бессерверных приложений на основе реляционных баз данных не придется управлять новой инфраструктурой или кодом. RDS Proxy является полностью управляемым и масштабирует свои ресурсы в зависимости от требований вашего приложения.

Прокси-сервер RDS доступен для версии Amazon Aurora, совместимой с MySQL, версии Amazon Aurora, совместимой с PostgreSQL, Amazon RDS для MariaDB, Amazon RDS для MySQL, Amazon RDS для PostgreSQL и Amazon RDS для SQL Server. Список поддерживаемых версий движков можно найти в Руководстве пользователя Amazon Aurora и в Руководстве пользователя Amazon RDS.

Чтобы включить Amazon RDS Proxy для базы данных Amazon RDS, потребуется всего лишь несколько щелчков в консоли Amazon RDS. При включении RDS Proxy следует указать VPC и подсети, к которым требуется обращаться к RDS Proxy. Пользователь Lambda может включить Прокси-сервер Amazon RDS для своей базы данных Amazon RDS и настроить функцию Lambda для доступа к нему всего в несколько щелчков в консоли Lambda.

Да. С помощью API Amazon RDS Proxy можно создать прокси-сервер, а затем определить целевые группы, чтобы связать его с определенными инстансами или кластерами баз данных. Пример:

Развертывание Amazon RDS без перерыва в обслуживании доступно в версии Amazon Aurora, совместимой с MySQL, Amazon RDS для MySQL и Amazon RDS для MariaDB.

Развертывание Amazon RDS без перерыва в обслуживании доступно в версии Amazon Aurora, совместимой с MySQL версии 5.6 и новее, RDS для MySQL версии 5.7 и новее и RDS для MariaDB версии 10.2 и новее. Подробнее о доступных версиях см. в документации по Aurora, RDS для MySQL и RDS для MariaDB.

Развертывание Amazon RDS без перерыва в обслуживании доступно во всех регионах AWS (за исключением регионов AWS в Китае) и регионах AWS GovCloud.

Вы платите одинаковую цену за выполнение рабочих нагрузок в средах с новыми версиями приложений и за их выполнение в средах с текущими версиями приложений. В стоимость использования инстансов без перерыва в обслуживании входят текущие стандартные цены на инстансы db.instance, стоимость хранения, стоимость операций ввода-вывода для чтения и записи и всех включенных функций, например резервного копирования и аналитики производительности Amazon RDS. Фактически вы платите двойную стоимость выполнения рабочих нагрузок на инстансе db.instance в течение периода использования развертывания без перерыва в обслуживании.

Например, у вас есть база данных RDS для MySQL 5.7, работающая на двух инстансах r5.2xlarge db.instance, основной инстанс базы данных и реплика чтения в регионе AWS us-east-1 с конфигурацией с несколькими зонами доступности (MAZ). Каждый инстанс r5.2xlarge db.instance настроен для использования Amazon Elastic Block Storge (EBS) общего назначения объемом 20 ГиБ. Вы создаете клон инстанса с текущей версией приложения с использованием развертывания Amazon RDS без перерыва в обслуживании, пользуетесь им 15 дней (360 часов), а затем удаляете инстансы с текущими версиями приложений после успешного переключения. Стоимость инстансов с текущими версиями приложений составляет 1387 USD за 15 дней по модели с оплатой по требованию по цене 1926 USD в час (стоимость инстанса + EBS). Общая стоимость использования развертывания без перерыва в обслуживании за эти 15 дней составит 2774 USD, что в два раза больше стоимости использования инстансов с текущими версиями приложений за тот же период.

При развертывании Amazon RDS без перерыва в обслуживании среда с текущей версией приложения является текущей рабочей средой. Среда с новой версией приложения – это промежуточная среда, которая станет новой рабочей средой после переключения.

При развертывании Amazon RDS без перерыва в обслуживании среда с текущей версией приложения является текущей рабочей средой. Среда с новой версией приложения – это промежуточная среда, которая станет новой рабочей средой после переключения.

Когда развертывание Amazon RDS без перерыва в обслуживании инициирует переключение, оно блокирует запись как в среду с новой версией приложения, так и в среду с текущей его версией до завершения переключения. Во время переключения промежуточная среда или среда с новой версией приложения «нагоняет» рабочую систему, гарантируя единство данных в промежуточной и рабочей средах. После полной синхронизации производственной и промежуточной сред развертывание без перерыва в обслуживании делает промежуточную среду производственной средой, перенаправляя трафик в новую распространенную производственную среду. Развертывание без перерыва в обслуживании предназначено для обеспечения записи в среду с новой версией приложения после завершения переключения, что гарантирует нулевую потерю данных во время переключения.

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

Ограничения переключения при развертывании Amazon RDS без перерыва в обслуживании блокируют операции записи в среду с текущей и в среду с новой версией приложения, пока последняя не синхронизируется полностью. Также развертывание без перерыва в обслуживании проводит проверки работоспособности основного хранилища и реплик в среде с текущей версией и среде с новой версией приложения. Кроме того, оно проводит проверки работоспособности репликации, например, чтобы проверить, не остановлена ли репликация или не произошли ли ошибки. Они выявляют долгие транзакции между средой с текущей версией и средой с новой версией приложения. Вы можете указать максимально приемлемое время простоя с минимальным значением 30 секунд, и если ваша текущая транзакция превышает это время, происходит тайм-аут переключения.

Нет. Развертывание Amazon RDS без перерыва в обслуживании не поддерживает глобальные базы данных, Прокси-сервер Amazon RDS, реплики чтения между регионами и каскадные реплики чтения.

Нет. На данный момент вы не можете использовать развертывание Amazon RDS без перерыва в обслуживании для отката изменений.

MySQL защищает пользователей от потери данных, записывая данные из страниц памяти размером 16 КиБ дважды в надежное хранилище: сначала в «буфер двойной записи», а затем в табличное хранилище. Оптимизированные операции записи Amazon RDS надежно записывают страницы памяти размером 16 КиБ непосредственно в файлы данных в один прием с использованием функции предотвращения обрыва записи системы AWS Nitro.

Оптимизированные операции записи Amazon RDS доступны для MySQL основной версии 8.0.30 и новее.

Оптимизированные операции записи Amazon RDS доступны для инстансов db.r6i и db.r5b. Они поддерживаются во всех регионах, где доступны эти инстансы, за исключением регионов AWS в Китае.

Всем пользователям Amazon RDS для MySQL следует реализовать оптимизированные операции записи Amazon RDS, чтобы повысить пропускную способность транзакций записи почти в два раза. Для приложений с рабочими нагрузками, которые интенсивно используют операции записи, такие как цифровые платежи, финансовый трейдинг и онлайн-игры, эта возможность будет особо полезной.

Нет. Версия Amazon Aurora, совместимая с MySQL, уже избегает использования «буфера двойной записи». Вместо этого Amazon Aurora реплицирует данные шесть раз в трех зонах доступности (AZ) и использует подход на основе кворума для надежной записи данных и последующего правильного их чтения.

На данный момент этот первоначальный выпуск не поддерживает включение оптимизированных операций записи Amazon RDS для существующих инстансов баз данных, даже если класс инстанса поддерживает оптимизированные операции записи.