Час простою для збільшення зберігання AWS RDS?

Я хочу збільшити обсяг зберігання двох екземплярів RDS (просто виділений простір, а не тип екземпляра чи інші параметри). Документація на https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html#USER_PIOPS.ModifyingExisting пропонує:

Ви можете перейти від стандартного сховища до Provisioned IOPS-накопичувача або з Provisioned IOPS до стандартного сховища, а також збільшити обсяг пам’яті, мало часу до простою.

Я б точно запланував вікно обслуговування перед тим, як виконати зміну. Але документація здається трохи невиразною у цій галузі. Для когось, хто, можливо, робив це раніше, що "мало не простоїв"? Чи можу я очікувати 5 секунд чи це більше, як 5 хвилин?

Оновлення липня 2019 року:

Я оновив посилання на правильну та оновлену документацію AWS (яка була зламана). Більш нова документація має розмиття, яке також допомагає відповісти на початкове запитання:

У більшості випадків масштабування сховища не вимагає відключення та не погіршує продуктивність сервера. Після зміни розміру пам’яті для екземпляра DB, статус екземпляра БД - оптимізація зберігання. Екземпляр БД повністю працює після зміни сховища. Однак ви не можете вносити подальші модифікації пам’яті ні на шість годин, ні в той час, коли стан екземпляра БД є оптимізацією пам’яті, залежно від того, що триває довше.

Однак, особливий випадок, якщо у вас є екземпляр DB SQL Server і ви не змінювали конфігурацію сховища з листопада 2017 року. У цьому випадку ви можете зазнати короткого відключення в кілька хвилин, коли ви модифікуєте екземпляр БД, щоб збільшити виділений зберігання. Після відключення екземпляр БД перебуває в мережі, але знаходиться в стані оптимізації зберігання. Під час оптимізації пам’яті продуктивність може знизитися.

По-перше, зауважте, що ви можете дивитися на неправильну операцію - ви описуєте, що хочете змінити розмір пам’яті , але цитували документацію, що описує тип зберігання . Це важливий розбіжність: RDS радить, що ви не відчуєте перебоїв щодо зміни розміру пам’яті, але відчуєте перебої в зміні типу пам’яті.

Очікуйте зниження продуктивності для зміни розміру пам’яті, тривалість і вплив якого залежатимуть від кількох факторів:

• Тип вашого примірника RDS
• Конфігурація
  • Це відбудеться під час технічного обслуговування?
  • Чи відбудуться ці зміни спочатку на вашому рабі Multi-AZ, а потім у відмову?
• Поточний розмір бази даних
• Розмір бази даних кандидата
• Ємність AWS для обробки цього запиту в потрібний час доби, в потрібній зоні доступності, у запитуваному регіоні
• Тип двигуна (для користувачів Amazon Aurora додатки для зберігання даних керуються RDS за необхідності з кроком 10 ГБ, тому ця дискусія є суперечкою)

Зважаючи на це, вам краще послужити, перевіривши це самостійно, у своєму оточенні та на своїх умовах. Спробуйте експериментувати з наступним:

• Відновлення нового екземпляра RDS зі знімка наявного екземпляра та виконання цієї операції на новому клоні.
• З цим клоном:
  • Збільште розмір у різний час дня, коли ви очікували б різного навантаження на AWS.
  • Збільшити до різних розмірів.
  • Спробуйте це з мульти-AZ. Подивіться, чи зміниться ваш реальний простой порівняно з тим, що не вмикається багатоазіатський AZ.
  • Спробуйте це під час вікна технічного обслуговування та порівняйте його із застосуванням зміни негайно.

Це коштуватиме трохи дорожче (не обов’язково ... ви могли б зробити більшу частину цього за 1-3 екземпляри години), але ви отримаєте набагато чіткішу відповідь, ніж розбиратись за наш досвід у безлічі різних RDS середовища.

Якщо ви все ще шукаєте відповідь "Ballpark", я б радив запланувати принаймні погіршення продуктивності в межах хвилин, а не секунд - знову дуже сильно залежати від вашого оточення та конфігурації.

Для довідки, я нещодавно застосував цю точну операцію, щоб додати 10 Гб до екземпляра типу 40 Гб db.m1.small у суботу вдень (в EST). Екземпляр залишався у стані, що змінюється, приблизно 17 хвилин. Зауважте, що стан модифікації не описує реальний час простою, а швидше тривалість операції . Ви не зможете застосувати додаткові зміни до фактичного екземпляра (хоча ви все ще можете отримати доступ до самої БД), і це також тривалість, на яку ви можете очікувати будь-якої погіршення продуктивності.

Якщо ви плануєте лише змінити розмір пам’яті, відключення є несподіваним, але зауважте, що це може статися, якщо ця зміна буде здійснена спільно з іншими операціями, такими як зміна ідентифікатора / класу екземпляра або типу зберігання.

Оскільки ви тільки збільшуєте обсяг пам’яті та не змінюєте тип екземпляра чи щось інше, простою не повинно бути, але під час операції може бути «знижена продуктивність».

Посилання, яке ви цитували, неоднозначне, оскільки воно обговорює зміну типу пам’яті одночасно, коли обговорюється зміна розміру пам’яті. Якщо ви замість цього перегляньте "Виділене зберігання" в таблиці тут:

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html

ви побачите, що він говорить лише про "Ефективність може бути погіршений", і нічого не стосується перебоїв (що, за його словами, виникає в деяких випадках при перемиканні типу пам’яті).

Для довідки, при зміні бази даних MySQL 15 ГБ на db.m3.medium на 20 ГБ на eu-west-1 протягом робочого дня підключення мого додатка до бази даних було безперебійним. Однак і читання / запис IOPS збільшилося до 400-700 / с трохи менше 20 хвилин, отже, я думаю, посилання на знижену продуктивність. Про це повідомлялося як для екземплярів бази даних з одним AZ, так і для кількох AZ. (Про цей випадок повідомлялося як про "модифікацію" трохи довше, ніж це - близько 25 хвилин.)

Природно, ви можете спробувати його на екземплярі db, ідентичному вашому виробничому db, перш ніж робити це на вашому екземплярі db виробництва, щоб ви могли сміливо бачити, як він поводиться у вашій ситуації, перш ніж робити це реально.