Общие вопросы

Что такое Amazon Aurora?

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

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

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

Совместима ли Amazon Aurora с MySQL?

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

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

Совместима ли Amazon Aurora с PostgreSQL?

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

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

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

Как начать работу с Aurora?

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

В каких регионах AWS доступен сервис Aurora?

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

Как можно выполнить миграцию с MySQL в Aurora и наоборот?

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

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

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

Как можно выполнить миграцию с PostgreSQL в 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.

Нужно ли менять драйверы клиентов для работы с версией Amazon Aurora, совместимой с PostgreSQL?

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

Производительность

Что значит «производительность, до пяти раз превосходящая MySQL»?

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

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

Что значит «производительность, превосходящая производительность PostgreSQL в три раза»?

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

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

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

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

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

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

Оплата

Сколько стоит использование Aurora?

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

Распространяется ли на Aurora уровень бесплатного пользования AWS?

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

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

Нет. Репликация в Amazon Aurora включена в цену. Цена определяется хранилищем, потребляемым на уровне базы данных, а не хранилищем, потребляемым на уровне виртуализированного хранилища в 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 – это конфигурация кластера баз данных, которая предлагает экономически эффективную цену для абсолютного большинства приложений с низким или умеренным количеством операций ввода-вывода. Используя стандартную конфигурацию Aurora, вы платите за инстансы баз данных, хранилище и операции ввода-вывода с оплатой по запросу.

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

Когда следует использовать оптимизированную для ввода-вывода конфигурацию Aurora?

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

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

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

Могу ли я переключаться между оптимизированной для ввода-вывода и стандартной конфигурацией Aurora?

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

Работает ли оптимизированная для ввода-вывода конфигурация Aurora с зарезервированными инстансами?

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

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

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

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

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

Какова стоимость оптимизированного чтения Amazon Aurora для Aurora PostgreSQL?

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

Аппаратное обеспечение и масштабирование

Каковы минимальные и максимальные лимиты для хранилища базы данных Amazon Aurora?

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

Как масштабировать вычислительные ресурсы, связанные с инстансом БД Amazon Aurora?

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

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

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

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

Резервное копирование и восстановление

Как включить резервное копирование для инстанса БД?

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

Можно ли делать снимки состояния БД и сохранять их в течение неограниченного времени?

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

Какова процедура восстановления при отказе базы данных?

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

Что происходит с резервными копиями и снимками состояния БД при удалении инстанса БД?

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

Можно ли использовать свои снимки состояния совместно с другим аккаунтом AWS?

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

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

Будет ли начисляться плата за совместно используемые снимки состояния?

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

Возможно ли автоматическое совместное использование снимков состояния?

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

С каким количеством аккаунтов можно совместно использовать снимок состояния?

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

В каких регионах можно совместно использовать снимки состояния базы данных Aurora?

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

Можно ли совместно использовать снимки состояния базы данных Aurora в разных регионах?

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

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

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

Высокая доступность и репликация

Как Amazon Aurora повышает отказоустойчивость базы данных к сбоям диска?

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

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

Как Aurora улучшает время восстановления после сбоя базы данных?

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

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

Какие типы реплик поддерживает Aurora?

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

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

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

Возможность Реплики Amazon Aurora
Реплики MySQL
Количество реплик До 15 До 5
Тип репликации Асинхронный (миллисекунды) Асинхронный (секунды)
Влияние на производительность первичного инстанса Низкое Высокое
Местоположение реплики В том же регионе
В другом регионе
Использование для обработки отказа Да (без потери данных) Да (потенциальная потеря данных, исчисляемая в минутах)
Автоматическая обработка отказа Да Нет
Поддержка определяемой пользователем задержки репликации Нет Да
Поддержка данных или схемы, отличающихся от данных или схемы первичного инстанса Нет Да

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

Можно ли при работе с Amazon Aurora использовать реплики в различных регионах?

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

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

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

Можно ли создавать реплики Aurora в межрегиональном кластере реплик?

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

Можно ли при обработке отказа переключать приложение с текущей основной реплики на межрегиональную реплику?

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

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

Можно ли указывать определенные реплики в качестве приоритетных целевых объектов при обработке отказа?

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

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

Можно ли изменять уровни приоритета инстансов после их создания?

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

Можно ли запретить перемещение определенных реплик в основной инстанс?

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

Как можно улучшить доступность единичной базы данных Amazon Aurora?

Можно добавить реплики 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 автоматически обнаруживает проблему в основном инстансе и запускает обработку отказа. При использовании адреса кластера соединения чтения/записи будут автоматически перенаправляться на реплику Amazon Aurora, которая будет преобразована в основной инстанс.

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

Насколько реплики отстают от первичного инстанса?

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

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

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

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

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

Что такое Глобальная база данных Amazon Aurora?

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

Как создать Глобальную базу данных Amazon Aurora?

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

Сколько дополнительных регионов может быть включено в Глобальную базу данных Amazon Aurora?

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

Если я использую Глобальную базу данных Amazon Aurora, можно также использовать логическую репликацию (binlog) в основной базе данных?

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

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

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

Безопасность

Можно ли работать с Amazon Aurora в Amazon Virtual Private Cloud (Amazon VPC)?

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

Выполняет ли Amazon Aurora шифрование данных в движении и хранении?

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

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

Можно ли зашифровать существующую незашифрованную базу данных?

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

Как получить доступ к базе данных Amazon Aurora?

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

Можно ли использовать Amazon Aurora с приложениями, для которых необходимо соответствие требованиям HIPAA?

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

Где можно получить доступ к пакету правил Common Vulnerabilities and Exposures (CVE) для проверки наличия известных уязвимостей новых выпусков Amazon Aurora?

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

Как обнаруживать угрозы безопасности базы данных Aurora?

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

Бессерверная конфигурация

Что такое Бессерверная конфигурация Amazon Aurora?

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

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

В чем разница между бессерверной конфигурацией Aurora версии 2 и версии 1?

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

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

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

Каков полный список возможностей Aurora, которые поддерживает бессерверная конфигурация Aurora версии 2?

Можно ли начать использовать бессерверную конфигурацию Aurora версии 2 с выделенными инстансами в текущем кластере БД Aurora?

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

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

Можно ли провести миграцию с Бессерверной конфигурации Aurora версии 1 на Бессерверную конфигурацию Aurora версии 2?

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

Какие версии Amazon Aurora поддерживает Бессерверная конфигурация Aurora?

Можно ли перенести существующий кластер базы данных Aurora в бессерверную конфигурацию Aurora?

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

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

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

Можно ли явным образом устанавливать объем ресурсов кластера Бессерверной конфигурации?

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

Почему кластер базы данных Aurora Serverless не масштабируется автоматически?

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

Как рассчитывается плата за бессерверную конфигурацию Aurora?

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

Параллельный запрос

Что такое Amazon Aurora Parallel Query?

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

Для каких примеров использования предназначена данная возможность?

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

В чем преимущества использования Parallel Query?

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

Эффективность выполнения каких запросов повышает Parallel Query?

Может быть повышена эффективность выполнения большинства запросов к большим наборам данных, которых еще нет в буферном пуле. Начальная версия Parallel Query может масштабировать и перенаправлять из обработки более 200 функций SQL, проекций и соединений по эквивалентности.

Насколько может возрасти производительность?

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

Возможно ли снижение производительности?

Да, но частого возникновения подобных случаев не ожидается.

Какие изменения следует внести в запрос, чтобы воспользоваться преимуществами Parallel Query?

Никаких изменений в синтаксис запроса вносить не требуется. Оптимизатор запросов автоматически определяет, стоит ли использовать Parallel Query для конкретного запроса. Чтобы выяснить, используется ли Parallel Query для выполнения запроса, просмотрите план выполнения запроса. Для этого запустите команду EXPLAIN. Если вы хотите обойти эвристику и запустить Parallel Query в тестовых целях, используйте переменную сеанса aurora_pq_force.

Как включить или выключить функцию Parallel Query?

Включить и выключить Parallel Query можно динамически с помощью параметра aurora_pq как глобально, так и на уровне сеанса.

Взимается ли дополнительная плата за использование Parallel Query?

Нет. Помимо стандартной платы за инстансы, операции ввода‑вывода и хранилище, никакие дополнительные платежи не взимаются.

Раз Parallel Query уменьшает количество операций ввода‑вывода, снизит ли использование данной функции стоимость этих операций для Aurora?

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

Возможное повышение стоимости операций ввода‑вывода при использовании Parallel Query обусловлено двумя причинами. Во‑первых, даже если часть данных таблицы уже находится в буферном пуле, Parallel Query требуется просмотреть все данные на уровне хранилища, что задействует операции ввода‑вывода. Во‑вторых, побочным эффектом предотвращения конфликтов в буферном пуле является то, что выполнение запроса с использованием Parallel Query не «разогревает» буферный пул. В результате, последовательное выполнение одного и того же запроса с использованием Parallel Query приводит к начислению полной стоимости операций ввода‑вывода.

Подробнее о Parallel Query см. в документации.

Доступна ли возможность Parallel Query на инстансах любых семейств?

Нет. В данный момент Parallel Query можно использовать на инстансах семейства R*.

Какие версии Amazon Aurora поддерживают Parallel Query?

Возможность Parallel Query доступна для версии Amazon Aurora, совместимой с MySQL 5.7 и MySQL 8.0.

Совместима ли возможность Parallel Query c другими возможностями Aurora?

Возможность Parallel Query совместима с бессерверной конфигурацией Aurora v2 и Backtrack.

Если Parallel Query ускоряет выполнение запросов и довольно редко вызывает спады производительности, можно ли просто включить эту возможность для всех баз данных на постоянной основе?

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

Может ли Aurora Parallel Query заменить собой хранилище данных?

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

Попробуйте Amazon Redshift для облачного хранилища данных в масштабе эксабайтов.

Оптимизированное чтение

Что такое оптимизированное чтение Amazon Aurora для Aurora PostgreSQL?

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

Как оптимизированное чтение Amazon Aurora для Aurora PostgreSQL повышает производительность запросов?

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

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

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

В каких случаях следует использовать оптимизированное чтение Amazon Aurora для Aurora PostgreSQL?

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

Какие типы инстансов баз данных поддерживают оптимизированное чтение Amazon Aurora для Aurora PostgreSQL? В каких регионах они доступны?

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

Какие версии движка Amazon Aurora поддерживает оптимизированное чтение Aurora для Aurora PostgreSQL?

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

Можно ли использовать оптимизированное чтение Amazon Aurora для Aurora PostgreSQL с бессерверной версией Aurora v2?

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

Можно ли использовать оптимизированное чтение Amazon Aurora для Aurora PostgreSQL со стандартной конфигурацией Aurora и оптимизированной конфигурацией для ввода-вывода?

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

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

Как начать работу с оптимизированным чтением Amazon Aurora для Aurora PostgreSQL?

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

Какую часть доступного локального хранилища можно использовать для оптимизированного чтения Amazon Aurora для Aurora PostgreSQL?

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

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

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

Что происходит в случае сбоя локального хранилища?

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

Как оптимизированное чтение Amazon Aurora для Aurora PostgreSQL влияет на задержку запроса в случае отказоустойчивости базы данных?

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

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

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

Генеративный искусственный интеллект

Что такое pgvector?

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

Какие возможности предоставляет pgvector для Aurora PostgreSQL?

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

Работает ли pgvector с машинным обучением Aurora?

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

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

Как оптимизированное чтение Aurora для Aurora PostgreSQL помогает повысить производительность pgvector?

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

Интеграции с нулевым использованием ETL

Когда следует использовать интеграцию Aurora с нулевым использованием ETL с Amazon Redshift?

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

Какие ядра и версии Amazon Aurora поддерживают интеграцию с нулевым использованием ETL?

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

Какие преимущества дает интеграция с нулевым использованием ETL?

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

Совместима ли интеграция с нулевым использованием ETL с бессерверной конфигурацией Aurora версии 2?

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

Как включить интеграцию с нулевым использованием ETL?

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

Сколько стоит интеграция с нулевым использованием ETL?

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

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

Amazon DevOps Guru для RDS

Что такое Amazon DevOps Guru для RDS?

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

Почему стоит использовать DevOps Guru для RDS?

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

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

Как работает Amazon DevOps Guru для RDS?

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

Как начать работу с Amazon DevOps Guru для RDS?

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

Какие типы проблем может обнаружить Amazon DevOps Guru для RDS?

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

Чем DevOps Guru для RDS отличается от Amazon RDS Performance insights?

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

API данных

Когда следует использовать API данных с Aurora вместо драйверов баз данных?

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

Какие подсистемы и версии Aurora поддерживают API данных?

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

Какие преимущества предоставляет API данных?

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

Поддерживает ли API данных Глобальную базу данных Aurora или бессерверную конфигурацию Aurora версии 1?

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

Как аутентифицироваться в базе данных с помощью API данных?

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

Сколько стоит API данных?

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

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

Почему AWS начала использовать события плоскости данных для API данных вместо событий управления CloudTrail?

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

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

Есть ли в API данных уровень бесплатного пользования?

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

Развертывания Amazon RDS без перерыва в обслуживании

Какие версии поддерживают развертывания Amazon RDS без перерыва в обслуживании?

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

В каких регионах поддерживаются развертывания Amazon RDS без перерыва в обслуживании?

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

В каких случаях необходимо использовать развертывания Amazon RDS без перерыва в обслуживании?

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

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

Сколько стоит использование развертываний Amazon RDS без перерыва в обслуживании?

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

Что случится с предыдущей рабочей средой после завершения переключения посредством развертывания Amazon RDS без перерыва в обслуживании?

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

Что контролируют ограничения переключения при развертываниях Amazon RDS без перерыва в обслуживании?

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

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

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

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

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

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

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

Надежные языковые расширения для PostgreSQL

Зачем следует использовать Trusted Language Extensions для PostgreSQL?

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

Каковы традиционные риски использования расширений в PostgreSQL и как TLE для PostgreSQL устраняет эти риски?

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

Какое отношение имеет TLE для PostgreSQL к другим сервисам AWS и как они вместе работают?

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

В каких версиях PostgreSQL можно использовать TLE для PostgreSQL?

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

В каких регионах доступен сервис Trusted Language Extensions для PostgreSQL?

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

Сколько стоит использование TLE?

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

Чем TLE для PostgreSQL отличается от расширений, доступных на данный момент в Amazon Aurora и Amazon RDS?

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

Каковы примеры расширений можно использовать с TLE для PostgreSQL?

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

Какие языки программирования можно использовать для разработки TLE для PostgreSQL?

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

Как развернуть расширение TLE для PostgreSQL?

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

Как расширения TLE для PostgreSQL взаимодействуют с базой данных PostgreSQL?

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

Откуда можно подробно узнать о проекте с открытым исходным кодом TLE для PostgreSQL?

Подробно узнать о проекте TLE для PostgreSQL можно на официальной странице TLE на GitHub.

Расширенная поддержка Amazon RDS

Можно ли использовать расширенную поддержку RDS с любой второстепенной версией?

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

Как оценить стоимость расширенной поддержки RDS?

Стоимость расширенной поддержки Amazon RDS зависит от трех факторов: 1) количество виртуальных ЦПУ или ACU, работающих на инстансе, 2) регион AWS и 3) количество прошедших лет после окончания стандартной поддержки.

Чтобы оценить стоимость, определите количество виртуальных ЦПУ в инстансе и подходящую цену за календарный год для вашей версии ядра. Если цена вашей версии рассчитана на 1–2 года и вы используете выделенные инстансы, то с вас будет взиматься плата, рассчитанная следующим образом: количество виртуальных ЦПУ x цена за час работы в выбранном регионе за 1–2 года. Если цена вашей версии рассчитана на 3 года и вы используете выделенные инстансы, то с вас будет взиматься плата, рассчитанная следующим образом: количество виртуальных ЦПУ x цена за час работы в выбранном регионе за 3 года.

Например, если вы используете инстанс db.r5.large сервиса Aurora версии 2, совместимой с MySQL, в Северной Вирджинии 30 декабря 2024 года, то есть в течение первого года расширенной поддержки RDS, с вас будет взиматься плата в размере 0,200 USD в час: 2 виртуальные ЦПУ x 0,100 USD за работу виртуального ЦПУ в час.

Когда Amazon Aurora начнет взимать плату за расширенную поддержку RDS?

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

Например, стандартная поддержка Aurora версии 2, совместимой с MySQL, заканчивается 30 ноября 2024 года. Если после 30 ноября 2024 года вы запустите инстанс сервиса Aurora версии 2, совместимой с MySQL, с вас будет взиматься плата за расширенную поддержку RDS на этом инстансе.

Нужно ли будет платить за расширенную поддержку RDS при использовании снимков состояния БД?

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

Когда перестанут приходить счета за расширенную поддержку RDS?

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

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

Стоимость расширенной поддержки RDS зависит от версии ядра, региона AWS и количества календарных лет с момента, когда истек срок действия стандартной поддержки этой версии. В течение первых двух лет после окончания стандартной поддержки с вас будет взиматься плата для 1-го и 2-го года в выбранном вами регионе за каждый час использования виртуального ЦПУ. Если расширенная поддержка RDS предоставляется третий год, с вас будет взиматься плата для 3-го года в выбранном вами регионе за каждый час работы виртуального ЦПУ, начиная с первого дня третьего года.

Например, 29 февраля 2024 года закончится стандартная поддержка Aurora версии 11, совместимой с PostgreSQL. Если вы работаете в регионе Восток США (Огайо), то в период с 1 апреля 2024 года по 31 марта 2026 года с вас будет взиматься плата в размере 0,100 USD за час работы виртуального ЦПУ. С 1 апреля 2026 года с вас будет взиматься плата в размере 0,200 USD за каждый час работы виртуального ЦПУ.

Как избежать оплаты за расширенную поддержку RDS?

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

Можно ли развертывать Amazon RDS без перерыва в обслуживании для перехода с версии с расширенной поддержкой RDS на стандартную?

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

Распространяются ли скидки на зарезервированные инстансы на расширенную поддержку RDS?

Нет, плата за расширенную поддержку RDS не зависит от стоимости инстансов. Поэтому на нее не распространяются скидки на зарезервированные инстансы.

Будет ли взиматься плата за расширенную поддержку RDS, даже если я перейду с RDS для MySQL версии 5.7 на Aurora MySQL версии 2 (на основе MySQL версии 5.7)?

Если вы перейдете с RDS для MySQL версии 5.7 на Aurora MySQL версии 2 до 29 февраля 2024 года, плата за расширенную поддержку RDS взиматься не будет. При переходе после 29 февраля 2024 года и до 30 ноября 2024 года с вас будет взиматься плата за расширенную поддержку RDS за количество часов работы MySQL версии 5.7 в Amazon RDS.

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

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

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

Например, если после 30 ноября 2024 года вы восстановите снимок состояния БД на новом инстансе БД на базе Aurora версии 2, совместимой с MySQL, для него будет начисляться плата по цене расширенной поддержки RDS для Aurora версии 2, совместимой с MySQL, до тех пор, пока вы не обновите его до версии 3 или более новой либо не удалите.

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

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

Подробнее о ценах на Amazon Aurora

Перейти на страницу цен
Готовы приступить к разработке?
Начало работы с Amazon Aurora
Есть вопросы?
Связаться с нами