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

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

Инстансы БД можно быстро создать с помощью Консоли управления 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 инстансов БД RDS для Oracle или RDS для SQL Server в рамках модели лицензирования «Лицензия включена». Все 40 инстансов можно использовать для Amazon Aurora, RDS для PostgreSQL, RDS для MySQL, RDS для MariaDB и RDS для 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: ограничения со стороны ПО отсутствуют.
• RDS для Db2: до 1 базы данных на инстанс

Ниже приведены несколько способов импорта данных в Amazon RDS:

• MySQL: утилиты mysqldump или mysqlimport
• Oracle: утилиты Data Pump, import/export или SQL Loader
• SQL Server: мастер импорта/экспорта, файлы полной резервной копии (.bak) или программа массового копирования (BCP)
• PostgreSQL: утилита pg_dump

Подробнее об импорте и экспорте данных см. в Руководстве по импорту данных для MySQL, Руководстве по импорту данных для Oracle, Руководстве по импорту данных для SQL Server, Руководстве по импорту данных для PostgreSQL или Руководстве по импорту данных для Db2.

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

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

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

Если предпочтительное еженедельное окно обслуживания не указывается при создании инстанса БД, ему присваивается значение по умолчанию, равное 30 минутам. Интервал обслуживания можно изменить, отредактировав инстанс БД в Консоли управления AWS с помощью API ModifyDBInstance или команды 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 Aurora
• Amazon RDS for PostgreSQL
• Amazon RDS для MySQL
• Amazon RDS for MariaDB
• Amazon RDS for SQL Server
• Amazon RDS for Oracle
• Amazon RDS для Db2

Подробнее об особенностях нумерации версий ядер см. на странице вопросов и ответов по каждому из ядер БД 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 для Db2

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

Указать любую из поддерживаемых в настоящее время версий (второстепенную и основную) можно при создании нового инстанса БД с помощью операции «Запустить инстанс БД» в Консоли управления AWS или с помощью 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 прекратит создание новых инстансов базы данных и кластеров с этими версиями. При этом существующие клиенты смогут продолжить работу с текущими базами данных. В зависимости от конкретных обстоятельств сроки решения рассматриваемой проблемы могут быть разными.

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

• Часы использования инстанса БД – в зависимости от класса использованного инстанса БД (например, 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 и 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 или 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 или команды describe‑reserved‑db‑instances. Если разовый платеж не удастся успешно выполнить к началу следующего расчетного периода, тариф со скидкой применен не будет.

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

Операции 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 (выбрав нужный инстанс БД и нажав кнопку «Изменить»), 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.

Подробности см. в разделе Хранилище для Amazon RDS.

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

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

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

Хранилище с выделенными IOPS (на основе SSD) сервиса 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.

Если аккаунт 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 (AWS KMS). В инстансе БД с шифрованием Amazon RDS все хранимые данные в состоянии покоя зашифрованы, так же как и автоматические резервные копии, реплики чтения и снимки состояния. Шифрование и дешифрование осуществляется по ходу работы. Подробнее об использовании KMS с Amazon RDS см. в Руководстве пользователя Amazon RDS.

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

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

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

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

Да. AWS CloudTrail – это веб‑сервис, который записывает вызовы API AWS для аккаунта и предоставляет файлы журналов. История вызовов 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 (SNS). Можно также создать правила AWS Config, чтобы определить, есть ли в ресурсах Amazon RDS требуемая конфигурация.

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

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

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

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

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

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

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

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

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

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

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

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

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

В RDS для PostgreSQL, RDS для MySQL, RDS для MariaDB, RDS для SQL Server, RDS для Oracle и RDS для ядер баз данных Db2 при преобразовании инстанса 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, и предпринять соответствующие меры для устранения ее последствий. Подробнее о решении проблем репликации см. в разделе «Устранение неполадок реплик чтения» Руководства пользователя Amazon RDS для MySQL или PostgreSQL. 

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

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

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

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

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

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

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

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

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

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

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

Основные преимущества аналитики баз данных CloudWatch включают указанные далее.

1. Простой сбор данных телеметрии: автоматический сбор метрик, журналов и отслеживаний базы данных, помогающий свести к минимуму время настройки.
2. Специально подобранные инструменты аналитики: готовые панели управления, оповещения и аналитические данные для мониторинга и оптимизации производительности баз данных при минимальной настройке, необходимой для начала работы.
3. Унифицированное представление CloudWatch: объединение данных телеметрии из нескольких баз данных в одном представлении для упрощения мониторинга.
4. Возможности искусственного интеллекта и машинного обучения: искусственный интеллект и машинное обучение используются для обнаружения аномалий, помогая сократить трудозатраты на устранение неполадок вручную.
5. Мониторинг контекста приложений: помогает пользователям соотносить производительность базы данных с производительностью приложений.
6. Представления на уровне парка и инстансов: обеспечивают как мониторинг парка на верхнем уровне, так и подробные представления инстансов для анализа основных причин.
7. Простая интеграция с AWS: компонент интегрируется с сервисом Отслеживание состояния приложений Amazon CloudWatch и AWS X-Ray, обеспечивая комплексную среду наблюдаемости.

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

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

При улучшенном мониторинге регистрируются метрики инстанса 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 для загрузки метрик в режиме, близком к реальному времени. Другой способ предполагает использование фильтров в журналах CloudWatch Logs для передачи всех необходимых метрик CloudWatch и интеграции приложения с CloudWatch. Подробности см. в Документации Amazon CloudWatch.

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

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

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

Аналитика баз данных CloudWatch отслеживает ресурсы и приложения Amazon RDS и Amazon Aurora в режиме реального времени и представляет данные с помощью настраиваемых панелей управления. Amazon DevOps Guru – это сервис машинного обучения, который анализирует метрики CloudWatch, чтобы определить поведение приложения с течением времени, обнаружить аномалии и предложить ценные выводы и рекомендации по решению проблем.

Кроме того, DevOps Guru анализирует данные из нескольких источников, включая AWS Config, AWS CloudFormation и AWS X-Ray. Панели управления CloudWatch можно использовать для мониторинга выводов DevOps Guru с помощью метрик, публикуемых в пространстве имен AWS/DevOps-Guru. Это позволяет просматривать все выводы и аномалии в едином представлении консоли CloudWatch.

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

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

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

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

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

Благодаря прокси-серверу Amazon RDS можно изменить подход к созданию современных бессерверных приложений, которые используют преимущества эффективности и простоты реляционных баз данных. Во-первых, с помощью 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 можно создать прокси-сервер, а затем определить целевые группы, чтобы связать его с определенными инстансами или кластерами баз данных. Пример

aws rds create-db-proxy 
        --db-proxy-name '…' 
        --engine-family <mysql|postgresql>       
        --auth [{}, {}] 
        --role-arn '…'
        --subnet-ids {}
        --require-tls <true|false>
        --tags {}
aws rds register-db-proxy-targets 
        --target-group-name '…'
        --db-cluster-identifier  '…'
        --db-instance-identifier '…'

Trusted Language Extensions (TLE) для PostgreSQL дает разработчикам возможность создавать высокопроизводительные расширения PostgreSQL и безопасно выполнять их на базе Amazon Aurora и Amazon RDS. Таким образом, расширения TLE сокращают время выпуска продукта на рынок и освобождают администраторов баз данных от обязательств в отношении сертификации пользовательского и стороннего кода для использования в рабочих нагрузках баз данных рабочей среды. Вы можете идти дальше, как только решите, что расширение отвечает вашим требованиям. С помощью TLE вендоры ПО (ISV) могут предоставлять новые расширения PostgreSQL клиентам, использующим Aurora и Amazon RDS.

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

TLE для PostgreSQL предоставляет несколько уровней защиты для уменьшения этого риска. TLE ограничивает доступ к системным ресурсам. Роль rds_superuser может определять, кому разрешено устанавливать определенные расширения. Однако эти изменения можно вносить с помощью TLE API. TLE ограничивает влияние дефекта расширения отдельным подключением к базе данных. В дополнение к этим мерам безопасности TLE предоставляет администраторам баз данных с ролью rds_superuser возможность точного онлайн-контроля, которая позволяет решать, кому разрешено устанавливать расширения, причем администраторы могут создать модель разрешений для их запуска.

Только пользователи с достаточными привилегиями могут запускать и создавать с помощью команды CREATE EXTENSION расширения TLE. Также администраторы баз данных могут создать список разрешенных «привязок PostgreSQL», необходимых для более сложных расширений, которые изменяют внутреннее поведение базы данных и обычно требуют повышенных привилегий.

TLE для PostgreSQL доступен для Версии Amazon Aurora, совместимой с PostgreSQL, и для Amazon RDS на PostgreSQL версии 14.5 и новее. Собственно TLE реализован как расширение PostgreSQL, и вы можете активировать этот сервис в роли ds_superuser подобно другим расширениям, которые поддерживаются в Aurora и Amazon RDS.

TLE для PostgreSQL можно использовать в PostgreSQL версии 14.5 или новее в Amazon Aurora и Amazon RDS.  

В настоящее время TLE для PostgreSQL доступен во всех регионах AWS (за исключением тех, что находятся в Китае) и в регионах AWS GovCloud.

TLE для PostgreSQL доступен для клиентов Aurora и Amazon RDS без дополнительной платы.

Aurora и Amazon RDS поддерживают специальный набор из более чем 85 расширений PostgreSQL. AWS управляет рисками безопасности для каждого из этих расширений с использованием Модели общей ответственности AWS. Расширение, которое реализует TLE для PostgreSQL, включено в этот набор. Расширения, которые вы пишете или получаете из сторонних источников и устанавливаете в TLE, считаются частью кода вашего приложения. Вы отвечаете за безопасность своих приложений, в которых используются расширения TLE.

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

В настоящее время TLE для PostgreSQL поддерживает JavaScript, PL/pgSQL, Perl и SQL.

Когда роль rds_superuser активирует TLE для PostgreSQL, вы можете развертывать расширения TLE с помощью команды SQL CREATE EXTENSION из любого клиента PostgreSQL, например psql. Это похоже на то, как создаются пользовательские функции, написанные на процедурном языке, таком как PL/pgSQL или PL/Perl. Вы можете управлять разрешениями пользователей на развертывание расширений TLE и использование определенных расширений.

TLE для PostgreSQL получает доступ к вашей базе данных PostgreSQL исключительно через API TLE. Доверенные языки, поддерживаемые TLE, содержат все функции интерфейса программирования сервера (SPI) PostgreSQL и поддерживают привязки PostgreSQL, в том числе привязку проверки пароля.

Более подробные сведения о проекте TLE для PostgreSQL приведены на официальной странице TLE на GitHub.

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

Развертывание Amazon RDS без перерыва в обслуживании доступно в Amazon Aurora, совместимой с MySQL версии 5.6 и новее, RDS для MySQL версии 5.7 и новее и RDS для MariaDB версии 10.2 и новее. Развертывание без перерыва в обслуживании также поддерживается в версии, совместимой с Amazon Aurora PostgreSQL, и Amazon RDS для PostgreSQL для версий 11.21 и новее, 12.16 и новее, 13.12 и новее, 14.9 и новее, 15.4 и новее. Чтобы узнать больше о доступных версиях, см. документацию об Amazon Aurora и об Amazon RDS. 

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

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

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

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

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

Рабочие нагрузки, использующие временные объекты в MySQL и MariaDB для обработки запросов, получают преимущества отоптимизированных операций чтения Amazon RDS. Оптимизированные операции чтения помещают временные объекты в хранилище инстансов на основе NVMe-инстанса базы данных, а не на том Amazon Elastic Block Store. Это помогает ускорить обработку запросов до 2 раз.

Оптимизированное чтение Amazon RDS доступно в RDS для MySQL в MySQL версии 8.0.28 и новее и RDS для MariaDB в MariaDB версий 10.4.25, 10.5.16, 10.6.7 и новее.

Оптимизированное чтение Amazon RDS доступно во всех регионах, где доступны инстансы db.r5d, db.m5d, db.r6gd, db.m6gd, X2idn и X2iedn. Дополнительную информацию см. в документации о классах инстансов баз данных Amazon RDS.

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

Да. Клиенты могут преобразовать существующие базы данных Amazon RDS для использования оптимизированного чтения Amazon RDS, перенеся рабочую нагрузку на инстанс, на котором используется оптимизированное чтение. Кроме того, оптимизированные операции чтения по умолчанию доступны на всех поддерживаемых классах инстансов. Если ваша рабочая нагрузка выполняется на инстансах db.r5d, db.m5d, db.r6gd, db.m6gd, X2idn и X2iedn, то вы уже пользуетесь преимуществами оптимизированных операций чтения.