Общие

Что такое Amazon Aurora?

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

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

Amazon 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что такое операции ввода‑вывода в Amazon Aurora и как они рассчитываются?

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

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

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

Каждая страница базы данных занимает 16 КБ в версии Aurora, совместимой с MySQL, или 8 КБ в версии Aurora, совместимой с PostgreSQL.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • При наличии реплики Amazon Aurora в той же или другой зоне доступности при обработке отказа Aurora переадресует запись канонического имени (CNAME) инстанса БД на здоровую реплику, которая в свою очередь, становится основной. Обработка отказа обычно полностью выполняется за 30 секунд. 
  • Если при работе с Aurora Serverless инстанс БД или зона доступности становятся недоступными, Aurora автоматически пересоздаст инстанс БД в другой зоне доступности. 
  • Если реплика Amazon Aurora отсутствует (т. е. есть только один инстанс) и вы не работаете с Aurora Serverless, ядро 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 Multi‑Master?

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

Как начать работу с Amazon Aurora Multi‑Master?

Возможность Amazon Aurora Multi-Master стала общедоступной. Подробнее читайте в документации Amazon Aurora. Вы можете создать кластер Aurora Multi-Master всего за несколько кликов в консоли Amazon RDS или скачать последний пакет AWS SDK или интерфейс командной строки (CLI).

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

Можно ли работать с 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?

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

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

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

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

Пакет правил CVE доступен на странице обновлений безопасности Amazon Aurora.

Бессерверные технологии

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

Бессерверная конфигурация Aurora – это конфигурация автоматического масштабирования, доступная по требованию для Amazon Aurora. Такая конфигурация позволяет запускать базу данных в облаке, исключая необходимость управления ее ресурсами вручную. Управление ресурсами базы данных вручную снижает эффективность их использования и отнимает ценное время. При использовании Aurora Serverless достаточно создать базу данных, указать желаемые пределы изменения ресурсов БД и подключить свое приложение. 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 Serverless (и наоборот).

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

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

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

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

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

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

Как рассчитывается плата за Aurora Serverless?

В Aurora Serverless ресурсы базы данных измеряются в единицах Aurora Capacity Units (ACU). Вы вносите фиксированную плату за каждую секунду использования ACU. Цены за объем хранилища и операции ввода/вывода одинаковы для конфигурации с выделенными ресурсами и бессерверной конфигурации. Посетите страницу цен Aurora, чтобы узнать актуальную информацию о стоимости и доступности регионов AWS.

Parallel Query

Что такое 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*.

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

В настоящее время нет. Пока данная возможность может быть включена только для кластеров баз данных, на которых не запущены возможности Serverless или Backtrack. Кроме того, Parallel Query не поддерживает особые возможности версии Aurora, совместимой с MySQL 5.7.

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

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

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

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

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

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

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

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