Вопросы и ответы по HAQM RDS для MySQL

Реляционная база данных HAQM (HAQM RDS) для MySQL в настоящее время поддерживает версии MySQL Community Edition 8.4 и 8.0. RDS для MySQL также поддерживает MySQL 5.7 в рамках расширенной поддержки RDS. Информацию о поддерживаемых второстепенных версиях см. в Руководстве пользователя HAQM RDS.

В MySQL версии нумеруются таким образом:
Версия MySQL = X.Y.Z

X = основная версия, Y = уровень релиза, Z = номер версии в серии релиза.
В HAQM RDS изменение версии считается основным, если изменилась основная версия или уровень релиза. Пример: переход от версии 5.6.X к версии 5.7.X.

Изменение версии считается второстепенным, если изменился номер версии в рамках одного релиза. Пример: переход от версии 5.6.27 к версии 5.6.29.

Да. Дополнительные сведения см. на странице вопросов и ответов для HAQM RDS.

Для восстановления на определенный момент времени, восстановления снимков состояния и интеграции с нулевым использованием ETL с функциями HAQM Redshift HAQM RDS для MySQL требуется механизм хранения данных с возможностью аварийного восстановления, и они поддерживаются только подсистемой хранилища InnoDB. Хотя MySQL поддерживает различные подсистемы хранилищ с различными функциями, не все из них оптимизированы для восстановления после сбоев и обеспечения надежного хранения данных. Например, ядро хранилища MyISAM не поддерживает надежное восстановление после сбоев, что может привести к потере или повреждению данных при перезапуске MySQL после сбоя, поскольку функции восстановления на момент времени и восстановления из снимков состояния не работают должным образом. Однако если вы решили использовать MyISAM с HAQM RDS, эти действия помогут при различных сценариях восстановления базы данных из снимков состояния. Федеративное ядро хранилища в настоящее время не поддерживается HAQM RDS для MySQL.

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

Реплики чтения RDS для MySQL требуют применения транзакционных ядер хранилища и поддерживаются только ядром хранилища InnoDB. При использовании нетранзакционных движков хранилища MySQL, например MyISAM, реплики чтения могут работать некорректно. Если вы все же будете использовать для реплик чтения движок MyISAM, мы рекомендуем в этом случае внимательно следить за метрикой Replica Lag в HAQM CloudWatch, которая доступна в Консоли управления AWS или с помощью API HAQM CloudWatch, и при запаздывании реплики чтения вследствие ошибок репликации создавать ее заново. Вышесказанное также справедливо при использовании временных таблиц и других нетранзакционных ядер.

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

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

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

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

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

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

Представим, что у вас есть база данных RDS для MySQL 5.7, работающая на базе двух инстансов r5.2xlarge db.instance, основного инстанса базы данных и реплики чтения в регионе AWS us-east-1 с конфигурацией с несколькими зонами доступности (MAZ). Каждый инстанс r5.2xlarge db.instance настроен для использования Магазина эластичных блоков HAQM (HAQM EBS) общего назначения объемом 20 ГиБ. После создания клона инстанса с текущей версией приложения посредством развертывания HAQM RDS без перерыва в обслуживании его можно использовать в течение 15 дней (360 часов). После успешного переключения инстансы с текущими версиями приложений необходимо удалить. Стоимость инстансов с текущими версиями приложений составляет 1387 USD за 15 дней по модели с оплатой по требованию по цене 1926 USD в час (стоимость инстанса + EBS). Общая стоимость использования развертывания без перерыва в обслуживании за эти 15 дней составит 2774 USD, что в два раза больше стоимости использования инстансов с текущими версиями приложений за тот же период.

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

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

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

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

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

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

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

Сервис MySQL защищает пользователей от потери данных, записывая данные из страниц памяти размером 16 КиБ дважды в надежное хранилище: сначала в «буфер двойной записи», а затем в табличное хранилище. Оптимизированная запись HAQM RDS обеспечивает запись страниц памяти размером 16 КиБ непосредственно в файлы данных в рамках одной операции посредством функции предотвращения обрыва записи системы AWS Nitro.

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

Оптимизированная запись HAQM RDS доступна для инстансов db.r6i и db.r5b. Они поддерживаются во всех регионах, где доступны эти инстансы, за исключением регионов AWS в Китае.

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

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

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

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

Производительность рабочих нагрузок, которые используют временные объекты в MySQL для обработки запросов, повышается благодаря оптимизированному чтению HAQM RDS. Оптимизированное чтение позволяет разместить временные объекты в хранилище инстансов на базе NVMe-инстанса базы данных, а не на томе HAQM EBS. Это помогает ускорить обработку сложных запросов до 50 %.

Оптимизированное чтение HAQM RDS доступно для RDS для MySQL в MySQL версии 8.0.28 и более новых версий.

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

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

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

Если вы хотите избавиться от необходимости создавать сложные конвейеры данных и управлять ими, следует использовать интеграцию HAQM RDS для MySQL с нулевым использованием ETL с HAQM Redshift. Как только данные будут помещены в HAQM Redshift, вы получите доступ к возможностям аналитики и машинного обучения (ML) для ваших транзакционных данных из RDS для MySQL в режиме, близком к реальному времени.

Интеграция RDS для MySQL с нулевым использованием ETL с HAQM Redshift доступна в поддерживаемых регионах AWS для версий MySQL 8.0.32 и выше.

Интеграция RDS для MySQL с нулевым использованием ETL с HAQM Redshift обеспечивает аналитику и машинное обучение в режиме, близком к реальному времени, на петабайтах транзакционных данных и устраняет необходимость создавать сложные конвейеры данных и управлять ими. Через несколько секунд после записи данных в RDS для MySQL они реплицируются в HAQM Redshift. Можно консолидировать данные из нескольких баз данных и таблиц от RDS для MySQL до HAQM Redshift. В зависимости от потребностей в аналитике фильтрация данных определенных баз данных и таблиц позволяет выборочно переносить данные в HAQM Redshift.

Вы платите за ресурсы RDS для MySQL и HAQM Redshift, используемые для создания и обработки данных об изменениях, полученных в рамках интеграции с нулевым использованием ETL. Эти ресурсы включают затраты на экспорт снимков состояния HAQM RDS для заполнения и повторной синхронизации хранилищ данных HAQM Redshift, затраты на отслеживание данных об изменениях (CDC) для непрерывной репликации данных об изменениях из источника в целевой объект, обычные операции ввода-вывода и хранилище RDS, используемые для обработки данных об изменениях, а также расходы на обычное хранение реплицированных данных и вычислительные операции по ним в HAQM Redshift. Дополнительные сведения см. на странице цен на RDS для MySQL.

Например, у вас есть база данных RDS для MySQL 8.0.32 и хранилище данных HAQM Redshift, работающие в регионе Восток США (Северная Вирджиния). Этот инстанс БД RDS для MySQL в настоящее время использует 50 ГБ хранилища SSD общего назначения (gp3), включая выделенное количество базовых операций ввода-вывода в секунду, и для него включено автоматическое резервное копирование и ведение бинарных журналов MySQL.

При создании интеграции с нулевым использованием ETL с HAQM Redshift для инстанса БД RDS для MySQL создается снимок состояния данных (50 ГБ), который экспортируется для заполнения хранилища данных HAQM Redshift. На следующий день вы меняете первичный ключ таблицы в инстансе БД RDS для MySQL, что приводит к повторной синхронизации экспорта снимков состояния в HAQM Redshift. В течение 30 дней база данных обрабатывает 5 ГБ изменений данных.

В этом примере стоимость использования интеграции RDS для MySQL с нулевым использованием ETL с HAQM Redshift в регионе Восток США (Северная Вирджиния) в течение 30 дней составляет 50 ГБ x (0,10 долл. США за ГБ) при первоначальном экспорте плюс 50 ГБ (0,10 долл. США за ГБ) затрат на повторную синхронизацию плюс 5 ГБ (2,00 долл. США за ГБ) за передачу данных при отслеживании данных об изменениях, что в сумме составляет 20,00 долларов США. Помимо этих затрат на интеграцию с нулевым использованием ETL, вы оплачиваете затраты на обычное использование HAQM RDS и HAQM Redshift для обработки реплицированных данных, такие как затраты на операции ввода-вывода, хранение данных и вычислительные операции.

Да, чтобы снизить потребление ресурсов на основном инстансе, можно использовать реплику чтения HAQM RDS в качестве исходного инстанса HAQM RDS для интеграции с нулевым использованием ETL с HAQM Redshift.

Да, AWS CloudFormation можно использовать для управления и автоматизации настройки и развертывания ресурсов, необходимых для интеграции RDS для MySQL с нулевым использованием ETL с HAQM Redshift. Подробнее см. в руководстве пользователя AWS CloudFormation.

Интеграция между RDS для MySQL и HAQM Redshift с нулевым использованием ETL предусматривает атомарную репликацию транзакций для обеспечения согласованности данных между исходной базой данных RDS для MySQL и целевым кластером в HAQM Redshift.

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

• В HAQM Redshift реплицируются только совершенные транзакции из RDS для MySQL. Несовершенные или отмененные транзакции не переносятся.
• Интеграция использует двухэтапныйэтапный процесс передачи для атомарного применения каждой транзакции к HAQM Redshift. Применяются либо все изменения данных в транзакции, либо не применяется ни одно из изменений, если есть ошибка.
• Между исходной и целевой базой данных обеспечивается согласованность транзакций. После репликации данные конкретной транзакции будут согласованы как в RDS для MySQL, так и в HAQM Redshift.
• Изменения схемы с помощью DDL или DML также применяются атомарно для поддержания целостности.
• Атомарное применение транзакций гарантирует отсутствие частичных транзакций или противоречивых состояний данных между базами данных.

Интеграция между RDS для MySQL и HAQM Redshift с нулевым использованием ETL предусматривает полную согласованность транзакций между исходной базой данных в RDS для MySQL и целевым кластером в HAQM Redshift.

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

• Такие операторы DDL, как CREATE TABLE, ALTER TABLE, DROP TABLE и т. д., автоматически реплицируются из RDS для MySQL в HAQM Redshift.
• В ходе интеграции выполняются необходимые проверки и корректировки таблиц HAQM Redshift на предмет изменений в реплицированных схемах. Например, при добавлении столбца в RDS для MySQL такой столбец добавится и в HAQM Redshift.
• Репликация и синхронизация схем автоматически происходят в режиме, близком к реальному времени, с минимальной задержкой между исходной и целевой базами данных.
• Согласованность схем сохраняется даже тогда, когда изменения в DML происходят параллельно с изменениями в DDL.