Вопросы и ответы об Amazon Aurora

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

Aurora использует отказоустойчивую распределенную систему хранилищ с возможностью самостоятельного восстановления, которая отделена от вычислительных ресурсов и автоматически масштабируется до 128 ТиБ на инстанс базы данных. Aurora обеспечивает высокую производительность и доступность с использованием до 15 реплик чтения с низкой задержкой, восстановление на момент времени, непрерывное резервное копирование в Простой сервис хранения данных Amazon (Amazon S3) и репликацию в трех зонах доступности.

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

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

Актуальные сведения о совместимости Amazon Aurora с новыми выпусками MySQL см. в документации.

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

Актуальные сведения о совместимости Amazon Aurora с новыми выпусками PostgreSQL см. в документации.

Amazon полностью поддерживает Aurora PostgreSQL и все расширения, доступные в Aurora. Если вам нужна поддержка для Aurora PostgreSQL, обратитесь в службу поддержки AWS. Если у вас есть активный аккаунт Поддержки AWS-премиум, можно обратиться в службу поддержки AWS-премиум с вопросами, касающимися работы Amazon Aurora.

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

Сведения о доступности Aurora по регионам см. здесь.

Ниже представлены варианты выполнения миграции из MySQL в Aurora и наоборот.

• Можно использовать стандартную утилиту mysqldump для экспорта данных из MySQL и утилиту mysqlimport для импорта данных в Aurora или наоборот.
• Можно также использовать функцию миграции Снимок состояния БД Amazon RDS для переноса снимка состояния БД Amazon RDS для MySQL в Aurora с помощью Консоли управления AWS.

У большинства наших клиентов процесс миграции в Aurora занимает менее часа, однако его продолжительность зависит от формата и объема пакета данных. Дополнительную информацию см. в техническом описании Рекомендации по миграции баз данных MySQL в Amazon Aurora.

Ниже представлены варианты выполнения миграции из PostgreSQL в Aurora и наоборот.

• Можно использовать стандартную утилиту pg_dump для экспорта данных из PostgreSQL и утилиту pg_restore для импорта данных в Aurora или наоборот.
• Можно также использовать функцию миграции Снимок состояния БД RDS для переноса снимка состояния БД Amazon RDS для PostgreSQL в Aurora с помощью Консоли управления AWS.

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

Для миграции баз данных с SQL Server на версию Amazon Aurora, совместимую с PostgreSQL, можно применить Babelfish для Aurora PostgreSQL. Ваши приложения будут работать без изменений. Для получения дополнительной информации ознакомьтесь с документацией о Babelfish.

Нет, Aurora работает со стандартными драйверами баз данных PostgreSQL.

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

Тестирование SysBench на инстансах r3.8xlarge демонстрирует, что Amazon Aurora выполняет более 500 000 операций SELECT в секунду и 100 000 операций UPDATE в секунду, что в пять раз превышает результаты MySQL при прохождении того же теста на том же оборудовании. Подробные инструкции о том, как самостоятельно воспроизвести это тестирование, см. в Руководстве по стандартному тестированию производительности Amazon Aurora, совместимой с MySQL.

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

Тестирование SysBench на инстансах r4.16xlarge демонстрирует, что количество выполняемых Amazon Aurora операций SELECT в секунду и операций UPDATE в секунду в три раза превышает результаты PostgreSQL при прохождении того же теста на том же оборудовании. Подробные инструкции о том, как самостоятельно воспроизвести это тестирование, см. в Руководстве по стандартному тестированию производительности Amazon Aurora, совместимой с PostgreSQL.

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

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

Ознакомиться с действующими ценами можно на странице цен на Aurora.

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

Нет. Репликация в Amazon Aurora включена в цену. Цена определяется хранилищем, потребляемым на уровне базы данных, а не хранилищем, потребляемым на уровне виртуализированного хранилища в Aurora.

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

• Если ваш запросный трафик может полностью обслуживаться из памяти или кэша, вы не будете платить за получение каких-либо страниц данных из памяти.
• Если ваш запросный трафик не может быть обслужен полностью из памяти, с вас будет взиматься плата за любые страницы данных, которые необходимо получить из хранилища.
  Каждая страница базы данных занимает 16 КБ в версии Amazon Aurora, совместимой с MySQL, или 8 КБ в версии Aurora, совместимой с PostgreSQL.

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

Операции ввода-вывода при записи исчисляются в единицах по 4 КБ. Например, запись журнала размером 1,024 байта считается одной операцией ввода‑вывода. Однако если размер записи журнала превышает 4 КБ, для ее сохранения потребуется более одной операции ввода-вывода.

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

Объем запросов ввода‑вывода, потребляемых инстансом Aurora, можно узнать в Консоли управления AWS. Чтобы найти объем потребляемых ресурсов ввода‑вывода, перейдите в раздел консоли Amazon RDS, найдите свой список инстансов, выберите в нем инстансы Aurora, а затем посмотрите на метрики VolumeReadIOPs и VolumeWriteIOPs в разделе мониторинга.

Дополнительные сведения о ценах на операции ввода-вывода см. на странице цен Amazon Aurora. При настройке кластеров баз данных на стандартную конфигурацию Aurora взимается плата за операции ввода-вывода для чтения и записи. При настройке кластеров баз данных на оптимизированную для ввода-вывода конфигурацию Amazon Aurora плата за операции ввода-вывода для чтения и записи не взимается.

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

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

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

Оптимизированная для ввода-вывода конфигурация Aurora – идеальный выбор, когда вам требуется предсказуемость расходов для любых приложений. Она обеспечивает улучшенную ценовую производительность для приложений с интенсивными операциями ввода-вывода, которым требуется высокая пропускная способность записи или выполнение аналитических запросов, обрабатывающих большие объемы данных. Если затраты клиентов на операции ввода-вывода превышают 25 % от общих расходов на Aurora, они могут сэкономить до 40 % на рабочих нагрузках с большим количеством операций ввода-вывода с помощью оптимизированной для ввода-вывода конфигурации Aurora.

С помощью функции, доступной в Консоли управления AWS, можно одним щелчком мыши изменить тип хранилища существующих кластеров баз данных на оптимизированную для ввода-вывода конфигурацию Aurora. Для этого изменения можно также вызвать Интерфейс командной строки AWS (AWS CLI) или AWS SDK.

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

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

Стоимость возврата, снимка состояния, экспорта или непрерывного резервного копирования при использовании оптимизированной для ввода-вывода конфигурации Aurora не меняется.

Да, плата за операции ввода-вывода, необходимые для репликации данных в разных регионах, продолжает взиматься. Оптимизированная для ввода-вывода конфигурация Aurora не взимает плату за операции ввода-вывода для чтения и записи, что отличается от репликации данных.

Дополнительная плата за оптимизированное чтение Amazon Aurora для Aurora PostgreSQL не взимается, кроме стоимости инстансов R6id на базе Intel и R6gd на базе Graviton. Дополнительную информацию см. на странице цен Aurora.

Минимальный объем хранилища – 10 ГБ. По мере использования базы данных объем хранилища Amazon Aurora будет автоматически увеличиваться до 128 ТиБ с шагом в 10 ГБ без снижения производительности базы данных. Выделять хранилище заранее не требуется.

Это можно сделать двумя способами: с помощью Бессерверной конфигурации Aurora и вручную.

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

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

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

Автоматическое непрерывное резервное копирование для инстансов БД в Amazon Aurora всегда включено. Резервное копирование не влияет на производительность базы данных.

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

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

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

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

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

За совместное использование снимка состояния несколькими аккаунтами плата не взимается. Однако плата может начисляться за сам снимок состояния, а также за любую базу данных, восстановленную из совместно используемых снимков состояния. Подробнее о ценах на Aurora.

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

Созданные вручную снимки состояния можно использовать совместно с 20 аккаунтами AWS. Если требуется совместно использовать снимок состояния с большим количеством аккаунтов (больше 20), можно либо сделать снимок состояния публичным, либо обратиться в службу поддержки для повышения лимита.

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

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

Да. Зашифрованные снимки состояния базы данных Aurora можно использовать совместно.

Amazon Aurora автоматически делит том базы данных на распределенные по нескольким дискам сегменты по 10 ГБ. Каждый блок тома базы данных в 10 ГБ шестикратно реплицирован в трех зонах доступности. Amazon Aurora обеспечивает автоматическую обработку потери до двух копий данных без снижения доступности операций записи базы данных и до трех копий без снижения доступности операций чтения.

Хранилище Amazon Aurora также способно к самостоятельному восстановлению. Блоки данных и диски непрерывно сканируются на наличие ошибок и автоматически восстанавливаются.

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

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

Amazon Aurora, совместимая с MySQL, и Amazon Aurora, совместимая с PostgreSQL, поддерживают реплики Amazon Aurora, которые используют тот же том данных, что и основной инстанс в том же регионе AWS. Сделанные в основном инстансе обновления видны всем репликам Amazon Aurora.

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

Можно гибко комбинировать использование этих двух типов реплик в зависимости от потребностей приложения:

Помимо перечисленных выше возможностей существуют еще два дополнительных варианта репликации. Для сильно ускоренной физической репликации данных между кластерами Aurora в разных регионах можно использовать возможность Amazon Global Database. А для репликации данных между базами данных MySQL, находящимися внутри сервиса Aurora и за его пределами (или даже за пределами платформы AWS), можно настроить самоуправляемую репликацию бинарных логов.

Да, вы можете настроить межрегиональные реплики Aurora с помощью физической или логической репликации. Физическая репликация, называемая Amazon Aurora Global Database, использует выделенную инфраструктуру, которая делает базы данных полностью доступными для приложения и способна реплицировать в пять вторичных регионов при средней задержке менее секунды. Она доступна в версии Aurora, совместимой с MySQL, и в версии Aurora, совместимой с PostgreSQL.

Для глобального чтения и аварийного восстановления с минимальной задержкой рекомендуется использовать Amazon Aurora Global Database.
Aurora поддерживает нативную логическую репликацию в каждом ядре базы данных (binlog для MySQL и слоты репликации PostgreSQL для PostgreSQL), поэтому реплицировать можно даже в базы данных Aurora (и не Aurora) из других регионов.

Версия Aurora, совместимая с MySQL, также предлагает простую в использовании функцию логических межрегиональных реплик чтения, которая поддерживает до пяти вторичных регионов AWS. Она основывается на однопоточной репликации бинарных логов MySQL, поэтому на задержку репликации будет влиять интенсивность изменений/применений и сетевые задержки между конкретными выбранными регионами.

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

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

Глобальная база данных Amazon Aurora позволяет назначить вторичный регион для полных рабочих нагрузок чтения и записи менее чем за минуту.

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

Дополнительную информацию о логике обработки отказа см. в руководстве пользователя Amazon Aurora.

Да. Уровень приоритета инстанса можно изменять в любое время. Изменение уровня приоритета само по себе не приводит к запуску обработки отказа.

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

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

Для увеличения доступности базы данных просто создайте от одной до 15 реплик в любой из трех зон доступности, и Amazon RDS будет автоматически включать их в список при выборе первичного инстанса в случае отказа базы данных. Используйте Amazon Aurora Global Database, если хотите, чтобы ваша база данных охватывала несколько регионов AWS. Это позволит реплицировать данные без снижения производительности базы данных, а также провести аварийное восстановление после регионального сбоя.

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

• При наличии реплики Aurora в той же или другой зоне доступности при обработке отказа Aurora переадресует запись канонического имени (CNAME) инстанса БД на здоровую реплику, которая становится основной. Обработка отказа обычно полностью выполняется за 30 секунд. Чтобы повысить отказоустойчивость и ускорить переключение на другой ресурс, рассмотрите возможность использования Прокси-сервера Amazon RDS, который автоматически подключается к отказоустойчивому инстансу БД с сохранением подключений приложений. Прокси-сервер делает переключение на резервный ресурс прозрачным для ваших приложений и сокращает время переключения на резервный ресурс до 66 %.
• Если при работе с бессерверной конфигурацией Aurora версии 1 инстанс БД или зона доступности становятся недоступными, Aurora автоматически пересоздает инстанс БД в другой зоне доступности. Aurora Serverless версии 2 работает по принципу предоставления отказоустойчивости и других функций высокой доступности. Дополнительные сведения приведены в разделе Бессерверная конфигурация Aurora версии 2 и высокая доступность. 
• Если реплика Aurora отсутствует (т. е. есть только один инстанс) и вы не работаете с бессерверной конфигурацией Aurora, ядро Aurora сначала попытается создать новый инстанс БД в той же зоне доступности, что и исходный инстанс. Замена исходного инстанса выполняется на основе принципа «разумных усилий» и может не состояться, к примеру, если существует проблема, которая значительно влияет на зону доступности.
  

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

Amazon Aurora автоматически обнаруживает проблему в основном инстансе и запускает обработку отказа. При использовании адреса кластера соединения чтения/записи будут автоматически перенаправляться на реплику Amazon Aurora, которая будет преобразована в основной инстанс.

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

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

Для межрегиональной репликации задержка логической репликации на основе бинарных логов может расти бесконечно в зависимости от интенсивности изменений/применений, а также задержки в сети. Однако при стандартных условиях следует ожидать задержку репликации в пределах одной минуты. Для межрегиональных реплик, созданных на основе физической репликации Глобальной базы данных Amazon Aurora, характерна задержка менее секунды.

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

Клиентам, которые используют Aurora, совместимую с MySQL 5.7, рекомендуется рассмотреть возможность организации репликации бинарных логов на основе глобальных идентификаторов транзакций (GTID). Это обеспечивает полную согласованность, которая гарантирует, что во время репликации не произойдет потери транзакций и не будут возникать конфликты – даже после аварийного переключения или длительного простоя.

Глобальная база данных Amazon Aurora – возможность, позволяющая одной базе данных Amazon Aurora охватывать несколько регионов AWS. Она реплицирует данные без снижения производительности базы данных, обеспечивает высокую скорость локального чтения в каждом регионе при средней задержке меньше секунды, а также позволяет провести аварийное восстановление после регионального сбоя. В маловероятном случае регионального снижения производительности или сбоя назначить вторичный регион для полных рабочих нагрузок чтения и записи можно быстрее, чем за минуту. Эта возможность доступна в версии Aurora, совместимой с MySQL, и в версии Aurora, совместимой с PostgreSQL.

Создать глобальную базу данных Aurora можно всего в несколько щелчков в Консоли Amazon RDS. Также можно для этого применить Пакет средств разработки ПО (SDK) AWS или интерфейс командной строки (CLI) AWS. В Глобальной базе данных Amazon Aurora на каждый регион должен быть распределен хотя бы один инстанс.

Для Глобальной базы данных Amazon Aurora можно создать до пяти дополнительных регионов.

Да. Если ваша цель – анализировать операции в базе данных, рекомендуется воспользоваться расширенным аудитом Aurora, общими журналами и журналами медленных запросов во избежание снижения производительности базы данных.

Нет. Если основной регион становится недоступен, можно вручную удалить вторичный регион из Глобальной базы данных Amazon Aurora и назначить для него полные рабочие нагрузки чтения и записи. Кроме того, новый регион необходимо задать в вашем приложении.

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

Да. Amazon Aurora использует протокол SSL (с шифрованием AES‑256) для защиты соединения между инстансом базы данных и приложением. Amazon Aurora поддерживает шифрование баз данных с использованием ключей, управляемых пользователем с помощью Сервиса управления ключами AWS (AWS KMS).

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

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

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

Да. Версии Aurora, совместимые с MySQL и PostgreSQL, соответствуют требованиям HIPAA. Вы можете использовать их для создания приложений, соответствующих требованиям HIPAA, и хранения информации, связанной со здравоохранением, включая защищенную медицинскую информацию (PHI), на основании заключенного с AWS соглашения о деловом сотрудничестве (Business Associate Addendum, BAA). Если договор BAA с AWS уже подписан, можно сразу начать использовать эти сервисы в аккаунтах, подпадающих под действие BAA. Чтобы узнать подробнее об использовании AWS для создания соответствующих требованиям приложений, см. раздел Медицинские учреждения.

С пакетом правил CVE можно ознакомиться на странице обновлений безопасности Amazon Aurora.

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

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

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

Бессерверная конфигурация Aurora версии 2 поддерживает любой тип рабочей нагрузки баз данных – от сред разработки и тестирования, веб-сайтов и приложений с непостоянной, прерывистой или непредсказуемой рабочей нагрузкой до самых требовательных и необходимых для бизнеса приложений, которые должны быть всегда доступны и обладать высокой масштабируемостью. Она масштабируется на месте путем добавления ЦП и памяти без необходимости в обработке отказа базы данных с переносом в больший или меньший инстанс. В результате масштабирование может проводиться даже во время длительных транзакций, блокировки таблиц и т. д.

Кроме того, ресурсы базы данных масштабируются с шагом всего лишь в 0,5 единиц ресурсов Aurora (ACU), потому объем ресурсов базы данных точно отвечает потребностям вашего приложения.

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

Бессерверная конфигурация Aurora версии 2 поддерживает все возможности выделенного варианта Aurora, в том числе реплики чтения, конфигурацию с несколькими зонами доступности, Глобальную базу данных Aurora, Прокси-сервер RDS и Аналитику производительности.

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

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

Да. Вы можете провести миграцию с Бессерверной конфигурации Aurora версии 1 на Бессерверную конфигурацию Aurora версии 2. Подробности см. в Руководстве пользователя по Amazon Aurora.

Сведения о совместимости Бессерверной конфигурации Aurora версии 1 см. здесь. Сведения о совместимости Бессерверной конфигурации Aurora версии 2 см. здесь.

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

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

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

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

В бессерверной конфигурации Aurora ресурсы базы данных измеряются в единицах AC. Вы вносите фиксированную плату за каждую секунду использования ACU. Вычислительные затраты на выполнение рабочих нагрузок в бессерверной конфигурации Aurora будут зависеть от выбранной конфигурации кластера баз данных: стандартной или оптимизированной для ввода-вывода конфигурации Aurora. Посетите страницу цен Aurora, чтобы узнать больше о стоимости и доступности регионов.

Оптимизированное чтение Amazon Aurora, доступное для Aurora PostgreSQL, – это новый вариант с соотношением цены и производительности, который позволяет сократить время ожидания запросов до 8 раз и снизить затраты до 30 % по сравнению с инстансами без него. Это решение идеально подходит для приложений с большими наборами данных, объем которых превышает объем памяти инстанса базы данных.

В инстансах оптимизированного чтения Amazon Aurora используется локальное блочное хранилище SSD на базе NVMe, доступное в инстансах r6gd на базе Graviton и r6id на базе Intel. Это позволяет сократить время ожидания запросов приложений с наборами данных, объем которых превышает объем памяти инстанса базы данных. Оптимизированное чтение включает такие улучшения производительности, как многоуровневое кэширование и временные объекты.

Многоуровневое кэширование позволяет сократить время ожидания запросов до 8 раз и до 30 % снизить затраты на приложения, требующие большого количества операций чтения и ввода-вывода, таких как операционные панели управления, обнаружение аномалий и поиск векторных сходств. Данные преимущества реализуются благодаря автоматическому переносу данных кэширования из буферного кэша базы данных в памяти в локальное хранилище для ускорения последующего доступа к этим данным. Многоуровневое кэширование доступно только для версии Amazon Aurora PostgreSQL с конфигурацией, оптимизированной для операций ввода-вывода Aurora.

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

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

Оптимизированное чтение Amazon Aurora доступно в инстансах R6id на базе Intel и R6gd на базе Graviton. Сведения о доступности Aurora по регионам см. здесь.

Оптимизированное чтение Amazon Aurora доступно для версии Aurora, совместимой с PostgreSQL, на инстансах R6id и R6gd. Поддерживаемые версии движка: 15.4 и выше, 14.9 и выше в Aurora PostgreSQL.

Оптимизированное чтение Amazon Aurora недоступно в бессерверной версии Aurora v2 (ASv2).

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

Для рабочих нагрузок с интенсивным вводом-выводом и большим объемом чтения оптимизированные инстансы с поддержкой чтения в Aurora PostgreSQL, настроенные на использование оптимизированной для ввода-вывода конфигурации Aurora, автоматически кэшируют данные, удаленные из памяти в локальном хранилище на базе NVMe, что позволяет снизить задержку выполнения запросов до 8 раз и до 30 % сократить затраты по сравнению с инстансами без нее для приложений с большими наборами данных, объем которых превышает объем памяти инстанса базы данных.

Клиенты могут начать работу с оптимизированным чтением Amazon Aurora с помощью Консоли управления AWS, Интерфейса командной строки (CLI) и SDK. По умолчанию оптимизированное чтение доступно для всех инстансов R6id и R6gd. Чтобы использовать эту возможность, клиенты могут просто изменить существующие кластеры баз данных Aurora, включив в них инстансы R6id и R6gd, или создать новые кластеры баз данных с использованием этих инстансов. Для начала ознакомьтесь с документацией оптимизированного чтения Amazon Aurora.

В инстансах R6id и R6gd для оптимизированного чтения можно воспользоваться примерно 90 % доступного локального хранилища. Aurora резервирует 10 % хранилища NVMe, чтобы снизить усиление записи на SSD. Распределение доступного хранилища зависит от того, какие функции оптимизированного чтения включены.

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

При применении оптимизированного чтения только с функцией временных объектов, доступное место на локальном диске также можно использовать для хранения временных объектов. Например, при использовании инстанса r6gd.8xlarge с функциями временных объектов и многоуровневого кэширования для этих объектов резервируется 534 ГиБ (то есть в 2 раза больше памяти), а для многоуровневого кэша – 1054 ГиБ.

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

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

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

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

pgvector – это расширение с открытым исходным кодом для PostgreSQL, поддерживаемое версией, совместимой с Amazon Aurora PostgreSQL.

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

Машинное обучение Aurora дает возможность выполнять этот процесс в режиме реального времени, позволяя обновлять вложения в Aurora PostgreSQL, периодически обращаясь к Amazon Bedrock или Amazon SageMaker, которые возвращают самые последние вложения из вашей модели.

Оптимизированное чтение Amazon Aurora PostgreSQL с помощью pgvector до 9 раз увеличивает количество запросов в секунду для векторного поиска при рабочих нагрузках, превышающих доступную память инстанса. Это возможно благодаря использованию многоуровневого кэширования, доступного в оптимизированном чтении, которое автоматически кэширует данные, удаленные из буферного кэша базы данных в памяти, в локальное хранилище для ускорения последующего доступа к этим данным.

Интеграцию Amazon Aurora с нулевым использованием ETL с Amazon Redshift следует использовать при необходимости доступа к транзакционным данным в режиме, близком к реальному времени. Эта интеграция позволяет использовать преимущества машинного обучения Amazon Redshift с помощью простых команд SQL.

Интеграция Amazon Aurora с нулевым использованием ETL с Amazon Redshift доступна в версии Aurora, совместимой с MySQL 3.05 (совместимой с MySQL 8.0.32) и более новых версий в следующих регионах: Восток США (Огайо), Восток США (Северная Вирджиния), Запад США (Орегон), Азиатско-Тихоокеанский регион (Токио), Азиатско-Тихоокеанский регион (Сингапур), Азиатско-Тихоокеанский регион (Сидней), Европа (Франкфурт), Европа (Ирландия) и Европа (Стокгольм). Интеграция Aurora с нулевым использованием ETL с Amazon Redshift доступна в версии Aurora, совместимой с PostgreSQL, для Aurora PostgreSQL 15.4 в регионе Восток США (Огайо).

Интеграция Aurora с нулевым использованием ETL с Amazon Redshift избавляет вас от необходимости создавать и обслуживать сложные конвейеры данных. Можно объединять данные из одного или нескольких кластеров баз данных Aurora в один кластер баз данных Amazon Redshift и выполнять аналитику и машинное обучение в режиме, близком к реальному времени, с помощью Amazon Redshift на петабайтах транзакционных данных из Aurora. 

Интеграция Aurora с нулевым использованием ETL с Amazon Redshift совместима с бессерверной конфигурацией Aurora, версия 2. Когда используется и бессерверная конфигурация Aurora, версия 2, и бессерверный Amazon Redshift, можно генерировать аналитику транзакционных данных в режиме, близком к реальному времени, без необходимости управлять инфраструктурой конвейеров данных.

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

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

• Дополнительные операции ввода-вывода и хранения, используемые за счет включения расширенного бинарного журнала
• Затраты на экспорт снимков состояния при первоначальном экспорте данных для заполнения баз данных Amazon Redshift
• Дополнительное хранилище Amazon Redshift для хранения реплицированных данных
• Затраты на передачу данных между зонами доступности при перемещении данных от источника к целевому объекту

Дополнительную информацию см. на странице цен на Aurora.

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

Amazon DevOps Guru для RDS реализован как дополнительная возможность Amazon DevOps Guru и предназначен для обнаружения проблем с производительностью и эксплуатацией для всех типов платформы Amazon RDS и десятков других типов ресурсов. DevOps Guru для RDS расширяет возможности DevOps Guru, позволяя обнаруживать, диагностировать и исправлять широкий набор проблем с базами данных в Amazon RDS (например, чрезмерное потребление ресурсов или плохое поведение отдельных запросов SQL).

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

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

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

Amazon DevOps Guru для RDS использует машинное обучение для анализа данных телеметрии, которые собирает Amazon RDS Performance Insights (PI). DevOps Guru для RDS не использует для своего анализа никакие данные, сохраненные в самой базе данных. Performance Insights оценивает метрику нагрузки на базу данных, которая собирательно описывает время работы приложения с базой данных, а также несколько метрик самой базы данных, таких как переменные состояния сервера в MySQL или таблицы pg_stat в PostgreSQL.

Чтобы начать работу с DevOps Guru для RDS, обязательно сначала включите Performance Insights на консоли RDS, а затем включите DevOps Guru в настройках баз данных Amazon Aurora. DevOps Guru позволяет выбрать для анализа весь аккаунт AWS, назначить конкретные стеки AWS CloudFormation для анализа в DevOps Guru или с помощью тегов AWS настроить группирование ресурсов для анализа в DevOps Guru.

Amazon DevOps Guru for RDS помогает обнаруживать широкий спектр проблем с производительностью, которые могут влиять на качество предоставления сервиса для приложения, в том числе скопления блокировок, лавинные подключения, регрессии SQL, конфликты процессора и ввода/вывода, проблемы с использованием памяти.

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

API данных следует использовать для новых современных приложений, в частности созданных с помощью AWS Lambda, которым требуется доступ к Aurora в модели «запрос-ответ». Управлять постоянными подключениями к базе данных и использовать драйверы баз данных вместо API данных следует, когда существующее приложение тесно связано с драйверами баз данных, когда запросы выполняются долго или когда разработчик хочет воспользоваться преимуществами таких функций базы данных, как временные таблицы или использование переменных сеанса.

Сведения о доступности API данных в регионах AWS и версиях баз данных для выделенных инстансов бессероверной конфигурации Aurora, версии 2 и Aurora можно найти в нашей документации. Клиентам, которые в настоящее время используют API данных для бессерверной Aurora версии 1, рекомендуется перейти на бессерверную Aurora версии 2, чтобы воспользоваться преимуществами обновленного API данных и более точного масштабирования бессерверной Aurora версии 2..

API данных позволит упростить и ускорить разработку современных приложений. API данных — это простой в использовании безопасный API на основе HTTP, который устраняет необходимость в развертывании драйверов баз данных, управлении пулами подключений на стороне клиента или настройке сложной сети VPC между приложением и базой данных. API данных также повышает масштабируемость за счет автоматического объединения и совместного использования подключений к базе данных, что снижает вычислительные затраты приложений, часто открывающих и закрывающих подключения. 

Существующий API данных для бессерверной Aurora версии 1 останется функцией бессерверной Aurora версии 1 как в версии, совместимой с PostgreSQL, так и в версии Aurora, совместимой с MySQL. API данных для выделенных инстансов Aurora и бессерверной Aurora версии 2 не поддерживает бессероверную Aurora версии 1. API данных для выделенных инстансов Aurora и бессерверной Aurora версии 2 поддерживают инстансы модуля записи Глобальной базы данных Aurora.

Пользователи могут вызывать операции API данных только в том случае, если у них есть на это разрешение. Администраторы могут предоставить пользователям разрешение на использование API данных, приложив политику Управления идентификацией и доступом AWS (AWS IAM), определяющую их привилегии. Вы также можете привязать политику к роли, если вы используете роли IAM. При вызове API данных вы можете передать учетные данные для кластера Aurora DB, используя секрет в Менеджере секретов AWS. 

Использование API данных в бессерверной Aurora версии 1 по-прежнему доступно без дополнительной оплаты. Стоимость API данных для выделенных инстансов бессеровной Aurora версии 2 и Aurora зависит от объема запросов API, как описано на странице с ценами на Aurora. API данных для бессеровной Aurora версии 2 и выделенных инстансов Aurora использует события плоскости данных AWS CloudTrail для регистрации активности вместо событий управления, как это было в случае с API данных для бессеровной Aurora версии 1.

Вы можете включить регистрацию событий данных через консоль CloudTrail, интерфейс командной строки или SDK, если хотите отслеживать эту активность. За это будет взиматься плата, указанная на странице с ценами CloudTrail. Кроме того, за использование Менеджера секретов AWS взимается плата, как указано на странице с ценами на Менеджер секретов AWS. 

AWS CloudTrail фиксирует активность API AWS в виде событий управления или событий данных. События управления CloudTrail (также именуемые «операции плоскости управления») показывают операции управления, выполняемые с ресурсами в вашем аккаунте AWS, такие как создание, обновление и удаление ресурса. События данных CloudTrail (также именуемые «операции плоскости данных») показывают операции, выполненные с ресурсом или внутри него в вашем аккаунте AWS.

API данных выполняет операции в плоскости данных, поскольку он отправляет запросы к данным в вашей базе данных Aurora. Поэтому мы будем регистрировать активность API данных как события данных, поскольку это является правильной классификацией событий. Плата за события данных CloudTrail будет взиматься только в том случае, если вы включите регистрацию событий данных.

Да, уровень бесплатного пользования API данных включает миллион запросов в месяц, суммированных по всем регионам AWS, за первый год использования. Через год клиенты начинают платить за API данных, как описано на странице с ценами на Aurora.

Развертывания Amazon RDS без перерыва в обслуживании доступны в версии 5.6 и более новых версиях, совместимых с Amazon Aurora MySQL, в версиях 11.21 и более новых версиях, 12.16 и более новых версиях, 13.12 и более новых версиях, 14.9 и более новых версиях, 15.4 и более новых версиях. Подробнее о доступных версиях см. в документации об Aurora.

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

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

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

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

Например, у вас есть кластер версии Aurora 5.7, совместимой с MySQL, который работает на двух инстансах r5.2xlarge db.instance: основном инстансе для записи и инстансе для чтения – в регионе AWS us-east-1. Каждый из инстансов r5.2xlarge db.instance настроен для хранилища объемом 40 ГиБ и выполняет 25 млн операций ввода-вывода в месяц. Пользователи могут создавать клон инстанса с текущей версией приложения с помощью развертываний Amazon RDS без перерыва в обслуживании в течение 15 дней (360 часов), при этом в каждом инстансе с новыми версиями приложений за это время выполняется по 3 млн операций ввода-вывода. После успешного переключения инстансы с текущими версиями приложений подлежат удалению. Стоимость инстансов с текущими версиями приложений (для записи и чтения) составляет 849,2 USD за 15 дней по модели с оплатой по требованию по цене 1,179 USD в час (стоимость инстанса + ввод-вывод). Стоимость инстансов с новыми версиями приложений (для записи и чтения) составляет 840,40 USD за 15 дней по модели с оплатой по требованию по цене 1,167 USD в час (стоимость инстанса + ввод-вывод). Общая стоимость использования развертывания без перерыва в обслуживании за эти 15 дней составит 1689,60 USD, что примерно в два раза больше стоимости использования инстансов с текущими версиями приложений за тот же период.

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

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

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

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

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

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

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

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

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

TLE для PostgreSQL доступен для Amazon Aurora, совместимой с PostgreSQL 14.5 или более поздней версии. TLE реализован как расширение PostgreSQL, и его можно активировать из роли rds_superuser аналогично другим расширениям, поддерживаемым Aurora.

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

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

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

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.