Przestój na zwiększenie pamięci masowej AWS RDS?

Chcę zwiększyć przechowywanie dwóch wystąpień RDS (tylko przydzielone miejsce, a nie typ wystąpienia lub inne parametry). Dokumentacja na https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html#USER_PIOPS.ModifyingExisting sugeruje:

Możesz zmienić ze standardowej pamięci na Provisioned IOPS lub z Provisioned IOPS na standardową pamięć, a także zwiększyć pojemność, bez krótkich przestojów.

Zdecydowanie zaplanowałbym okno konserwacji przed wykonaniem zmiany. Ale dokumentacja wydaje się nieco niejasna w tej dziedzinie. Dla kogoś, kto mógł to zrobić wcześniej, czym jest „mało przestojów”? Czy mogę się spodziewać 5 sekund, czy może więcej niż 5 minut?

Aktualizacja lipca 2019 r .:

Zaktualizowałem link do poprawnej i zaktualizowanej dokumentacji AWS (która była zepsuta). Nowsza dokumentacja zawiera napis, który pomaga również odpowiedzieć na pierwotne pytanie:

W większości przypadków skalowanie pamięci nie wymaga żadnego przestoju i nie zmniejsza wydajności serwera. Po zmodyfikowaniu rozmiaru pamięci dla instancji DB stanem instancji DB jest Optymalizacja pamięci. Instancja DB jest w pełni operacyjna po modyfikacji magazynu. Nie można jednak dokonywać dalszych modyfikacji pamięci ani przez sześć godzin, ani gdy stan instancji bazy danych to optymalizacja pamięci, w zależności od tego, który z tych okresów jest dłuższy.

Jednak szczególny przypadek występuje, jeśli masz instancję bazy danych SQL Server i nie zmodyfikowałeś konfiguracji pamięci masowej od listopada 2017 r. W takim przypadku może wystąpić krótki przestój trwający kilka minut po zmodyfikowaniu instancji bazy danych w celu zwiększenia przydzielonej alokacji przechowywanie. Po awarii instancja bazy danych jest w trybie online, ale jest w stanie optymalizacji magazynu. Wydajność może zostać obniżona podczas optymalizacji pamięci.

Po pierwsze, zauważ, że możesz patrzeć na niepoprawną operację - opisujesz, że chcesz zmienić rozmiar pamięci , ale zacytowałeś dokumentację opisującą typ pamięci . Jest to ważne rozróżnienie: RDS informuje, że nie wystąpi awaria przy zmianie wielkości pamięci, ale wystąpi awaria przy zmianie rodzaju pamięci.

Oczekuj obniżonej wydajności przy zmianie rozmiaru pamięci, której czas trwania i wpływ będzie zależał od kilku czynników:

• Twój typ wystąpienia RDS
• Konfiguracja
  • Czy nastąpi to podczas konserwacji?
  • Czy zmiany te pojawią się najpierw w twoim slave'u Multi-AZ, a następnie w trybie failover?
• Aktualny rozmiar bazy danych
• Rozmiar bazy danych kandydata
• Zdolność AWS do obsługi tego żądania o żądanej porze dnia, w żądanej strefie dostępności w żądanym regionie
• Typ silnika (dla użytkowników Amazon Aurora dodatkami do pamięci zarządza RDS w razie potrzeby w przyrostach co 10 GB, więc dyskusja jest dyskusyjna)

Mając to na uwadze, lepiej byłoby Ci służyć, testując to samodzielnie, w swoim środowisku i na własnych warunkach. Spróbuj eksperymentować z następującymi elementami:

• Przywracanie nowego wystąpienia RDS z migawki istniejącego wystąpienia i wykonywanie tej operacji na nowym klonie.
• Z tym klonem:
  • Zwiększ rozmiar o różnych porach dnia, kiedy spodziewasz się innego obciążenia AWS.
  • Zwiększ do różnych rozmiarów.
  • Wypróbuj z Multi-AZ. Sprawdź, czy Twoje rzeczywiste przestoje ulegają zmianie w porównaniu z brakiem włączenia wielu AZ.
  • Wypróbuj go w oknie konserwacji i porównaj z natychmiastowym zastosowaniem zmiany.

Będzie to kosztować nieco więcej (nie musisz ... możesz zrobić większość z nich w ciągu 1-3 godzin instancji), ale dostaniesz o wiele czystszą odpowiedź niż handlowanie naszymi doświadczeniami w niezliczonej liczbie RDS środowiska.

Jeśli nadal szukasz odpowiedzi typu „ballpark”, radzę zaplanować przynajmniej obniżenie wydajności w ciągu kilku minut, a nie sekund - znowu bardzo zależy to od twojego środowiska i konfiguracji.

Dla porównania, ostatnio zastosowałem tę dokładną operację, aby dodać 10 GB do 40 GB instancji typu db.m1.small w sobotnie popołudnie (w EST). Instancja pozostawała w stanie „modyfikującym” przez około 17 minut. Należy zauważyć, że stan modyfikacji nie opisuje rzeczywistego czasu przestoju, ale raczej czas trwania operacji . Nie będziesz w stanie zastosować dodatkowych zmian do rzeczywistej instancji (chociaż nadal możesz uzyskać dostęp do samej bazy danych), a to także czas, w którym możesz spodziewać się spadku wydajności.

Jeśli planujesz tylko zmienić rozmiar pamięci, awaria jest nieoczekiwana, ale pamiętaj, że może się zdarzyć, jeśli ta zmiana zostanie wprowadzona w połączeniu z innymi operacjami, takimi jak zmiana identyfikatora / klasy instancji lub typu pamięci.

Ponieważ zwiększasz tylko rozmiar pamięci i nie zmieniasz typu instancji ani niczego innego, nie powinno być żadnych przestojów, ale podczas operacji może wystąpić „obniżona wydajność”.

Przywołane przez ciebie odniesienie jest niejednoznaczne, ponieważ omawia zmianę typu pamięci masowej w tym samym czasie, co dyskutuje o zmianie wielkości pamięci masowej. Jeśli zamiast tego spojrzysz na „Przydzielone miejsce” w tabeli tutaj:

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

zobaczysz, że mówi tylko „Wydajność może być obniżona” i nic o awarii (co, jak mówi, występuje w niektórych przypadkach po zmianie typu pamięci).

Dla porównania, podczas zmiany bazy danych MySQL db.m3.medium na 15 GB na 20 GB w eu-west-1 w ciągu dnia roboczego, połączenie mojej aplikacji z bazą danych było nieprzerwane. Jednak zarówno odczyt / zapis IOPS wzrósł do 400-700 / s przez nieco mniej niż 20 minut, stąd przypuszczam, że odniesienia do obniżonej wydajności. Zgłoszono to zarówno dla instancji bazy danych z pojedynczym AZ, jak i z wieloma AZ. (Instancja została zgłoszona jako „modyfikująca” trochę dłużej niż około - około 25 minut).

Naturalnie możesz wypróbować go na instancji db identycznej z produkcyjną db przed wykonaniem go na produkcyjnej instancji db, abyś mógł bezpiecznie zobaczyć, jak zachowuje się w twojej sytuacji, zanim zrobisz to naprawdę.