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

Вопрос. Что такое Amazon Aurora?

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

Вопрос: Что означает «совместимость с MySQL»?

Это означает, что большая часть кода, приложений, драйверов и инструментов, уже используемых сегодня с базами данных MySQL, может использоваться с Aurora лишь с незначительными модификациями или вовсе без них. Ядро базы данных Amazon Aurora совместимо с MySQL 5.6 и 5.7 при использовании подсистемы хранилища InnoDB. Некоторые функции MySQL, такие как ядро хранилища MyISAM, в Amazon Aurora не доступны.

Вопрос: Что означает «совместимость с PostgreSQL»?

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

Вопрос: Как можно попробовать работать с Amazon Aurora?

Чтобы попробовать Amazon Aurora, войдите в Консоль AWS, выберите пункт RDS в категории «Database» (Базы данных) и выберите Amazon Aurora в качестве ядра БД.

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

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

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

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

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

Актуальная информация по регионам и ценам находится на странице цен.

Вопрос: Как можно перейти от MySQL к Amazon Aurora и наоборот?

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

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

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

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

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

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

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

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

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

Вопрос: Нужно ли менять драйверы клиентов для работы с 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 Аврора будет автоматически расти до 64 ТБ с шагом в 10 ГБ, не снижая производительности базы данных. Необходимости выделять хранилище заранее нет.

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

Вычислительные ресурсы, выделенные инстансу БД, можно масштабировать в Консоли управления AWS, выбрав нужный инстанс БД и нажав кнопку «Modify». Ресурсы памяти и ЦПУ масштабируются за счет изменения класса инстанса БД.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да. Aurora MySQL позволяет настроить межрегиональные реплики Aurora с помощью логической или физической репликации.

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

На данный момент Aurora, совместимая с PostgreSQL, межрегиональную репликацию не поддерживает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вопрос: Что происходит во время обработки отказа и сколько времени это занимает?

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

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

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

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

Вопрос: Что произойдет в случае, если имеется основная база данных и реплика Amazon Aurora, активно обслуживающая трафик операций чтения, и происходит обработка отказа?

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

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

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

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

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

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

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

Вопрос: Что такое Amazon Aurora Global Database?

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

Эта возможность доступна для Amazon Aurora MySQL.

Вопрос. Как создать глобальную базу данных Aurora?

Создать глобальную базу данных Aurora можно всего в несколько щелчков в Консоли управления Amazon RDS. Либо можно воспользоваться SDK или CLI. В глобальной базе данных Aurora на каждый регион должен быть распределен хотя бы один инстанс.

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

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

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

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

Вопрос: Что такое Amazon Aurora Multi‑Master?

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

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

Сейчас возможность Amazon Aurora Multi‑Master доступна в ознакомительном режиме для совместимого с MySQL варианта БД 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 Key Management Service (KMS). В инстансе БД Amazon Aurora с шифрованием шифруются все данные, хранимые в базовой системе хранения, а также их автоматические резервные копии, снимки состояния и реплики чтения в том же кластере. Шифрование и дешифрование осуществляются незаметно для пользователя. Дополнительную информацию об использовании 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. Если договор BAA с AWS еще не заключен или у вас есть вопросы о приложениях на AWS, соответствующих требованиям HIPAA, свяжитесь с нами.

Serverless

Вопрос: Что такое Amazon Aurora Serverless?

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

Вопрос: Какие версии Amazon Aurora поддерживают Aurora Serverless?

В настоящий момент решение Aurora Serverless доступно для сервиса Aurora, совместимого с MySQL 5.6.

Вопрос: Можно ли перенести существующий кластер БД Aurora в конфигурацию Aurora Serverless?

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

Вопрос: Как подключиться к кластеру БД Aurora Serverless?

Доступ к кластеру БД Aurora Serverless можно получить из клиента, запущенного в том же Amazon Virtual Private Cloud (VPC). Назначить кластеру БД Aurora Serverless публичный IP‑адрес нельзя.

Вопрос: Можно ли явным образом устанавливать объем ресурсов кластера Aurora Serverless?

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

Вопрос: Почему кластер БД Aurora Serverless не масштабируется автоматически?

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

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

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

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

Вопрос: Что такое 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?

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

Вопрос: Как включить или выключить данную возможность?

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

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

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

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

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

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

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

Возможность Parallel Query доступна для версий Amazon Aurora, совместимых с MySQL 5.6, начиная с версии 1.18.0. Планируется, что в дальнейшем возможность Parallel Query станет доступна для версий Aurora, совместимых с MySQL 5.7 и PostgreSQL.

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

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

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

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

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

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

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

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

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

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