Как переключаться между стандартной и бессерверной конфигурациями в Amazon Aurora

Я ищу эту страницу Amazon - https://aws.amazon.com/rds/aurora/serverless/, и у него есть такая цитата:

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

У меня есть несколько обычных кластеров Aurora, и я хочу переключить их на бессерверные. Я искал и искал и не могу найти бит «мигрировать с помощью нескольких щелчков мышью» в пользовательском интерфейсе Amazon. Я отлично создал новый бессерверный кластер, поэтому я мог выполнять остановку, резервное копирование и восстановление с кратковременным отключением - но если бы я мог сделать это без сбоя, это было бы намного лучше.

Так где же эти «несколько щелчков мыши» - или, возможно, вы скажете мне, что «несколько щелчков» означают остановку, резервное копирование и восстановление. В любом случае, я думаю, многим было бы полезно знать, какие «несколько щелчков мышью» делают это возможным.


amazon-aurora
person drchuck    schedule 28.07.2018    source источник

Ответы (4)


arrow_upward
6
arrow_downward

В качестве комментария к подходу @drchuck. Мы на собственном горьком опыте убедились, что AWS Database Migration Service плохо справляется с созданием схемы в целевой базе данных. Однако есть простой обходной путь:

1) Запустите mysqldump --no-data, чтобы получить точную схему из исходной базы данных.

2) Выполните схему дампа в целевой базе данных.

3) В вашей задаче DMS в режиме подготовки целевой таблицы выберите «Усечь» вместо «Перетащить таблицы в целевую». (https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.Creating.html)

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

Мы использовали этот подход для сокращения простоев несколько раз.

person daveross1212    schedule 16.04.2019

arrow_upward
4
arrow_downward

Чтобы вычислить эти несколько кликов, потребовалось больше времени.

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

Сначала вы делаете снимок, а затем восстанавливаете его. В процессе восстановления вы можете выбрать бессерверный экземпляр. (По крайней мере, при НЕКОТОРЫХ условиях. Я не думаю, что 5.7.12 (только что подтвержденный на самом деле) может быть восстановлен до бессерверной конфигурации).

Подозреваю, что 5.7.12 будет в свое время.

Прямо сейчас волшебная палочка - начать с версии 5.6.10a, сделать снимок и затем восстановить его в не обслуживаемом экземпляре.

person Techmag    schedule 17.09.2018
comment
Я подтвердил, что это работает с производственной базой данных. Я начал со снимка, сделал восстановление в бессерверном режиме, и все заработало нормально. Вся база данных вместе с индексами осталась невредимой. - person Techmag; 18.09.2018

arrow_upward
2
arrow_downward

За что стоит по прошествии долгого времени:

Очевидно, Amazon Aurora Serverless совместим только с MySQL 5.6 - это объясняет, почему моментальные снимки 5.7 не могут быть восстановлены.

Итак, есть два варианта:

  • сначала понизить версию MySQL до 5.6 или
  • сброс и импорт данных (после прочтения других ответов я бы выбрал второй вариант).

Дополнительная литература: https://aws.amazon.com/rds/aurora/serverless/?nc1=h_ls#How_to_Get_Started

person Christopher    schedule 10.04.2020

arrow_upward
0
arrow_downward

Когда я не получил ответа через несколько дней, я сделал преобразование двумя способами с разными результатами, поэтому решил поделиться своими результатами здесь. Я все еще хотел бы услышать лучший подход. (1) Когда я выполнял преобразование с помощью mysqldump и restore, с небольшим отключением все было в порядке. (2) Когда я использовал AWS Database Migration Service, все прошло очень плохо.

Во-первых, вы должны получить двоичный формат журнала как «ROW» и срок хранения до 24 часов. Это потребовало перезапуска сервера на моих старых кластерах. Затем, когда миграция данных сработала, я потерял все свои автоматические приращения, а затем NULL в моих столбцах, предложения UNIQUE и внешние ключи в новых таблицах. Буквально единственное, что перенесено правильно, - это фактические данные и индикация PRIMARY KEY. Кроме того, я бы рекомендовал переносить одну базу данных за раз (т.е. схему) и не пытаться переносить внутренние схемы mysql. Я сказал «перенести все», и инструмент миграции попытался перенести материал MySQL - блин.

Единственное, что было действительно круто с помощью AWS Database Migration Service, - это миграция и мониторинг (что стало возможным благодаря ведению двоичного журнала в строках). Вы могли наблюдать, как он перемещает ряды.

person drchuck    schedule 31.07.2018