AWS RDS depolamasının arttırılması için kapalı kalma süresi?

İki RDS örneğinin depolanmasını artırmak için çalışıyorum (yalnızca örnek türünü veya diğer parametreleri değil, yalnızca ayrılmış depolama alanını). Https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html#USER_PIOPS.ModifyingExisting adresindeki belgeler :

Standart depolama alanından Provisioned IOPS depolamaya veya Provisioned IOPS'den standart depolamaya geçebilir, ayrıca depolama süresini artırabilir veya hiç kesinti olmadan değiştirebilirsiniz.

Değişikliği yapmadan önce kesinlikle bir bakım penceresi planlarım. Ancak belgeler bu alanda biraz belirsiz görünüyor. Bunu daha önce yapmış olabilecek biri için "az veya hiç kesinti" nedir? 5 saniye bekleyebilir miyim yoksa 5 dakika kadar mı?

Temmuz 2019’da güncelleme:

Bağlantıyı, doğru ve güncellenmiş AWS belgelerine (kırılmış) güncelledik. Yeni dokümantasyonda asıl soruya cevap vermeye yardımcı olan bir bulanıklığı var:

Çoğu durumda, ölçeklendirmenin depolanması kesinti gerektirmez ve sunucunun performansını düşürmez. Bir DB örneği için depolama boyutunu değiştirdikten sonra, DB örneğinin durumu Depolama optimizasyonudur. DB örneği, bir depolama değişikliğinden sonra tamamen çalışır durumda. Ancak, altı saat boyunca veya DB örneği durumu, hangisi daha uzunsa, depolama optimizasyonu durumunda başka depolama değişiklikleri yapamazsınız.

Ancak, bir SQL Server DB örneğiniz varsa ve depolama yapılandırmasını Kasım 2017'den bu yana değiştirmediyseniz özel bir durum söz konusudur. Bu durumda, tahsisatını artırmak üzere DB örneğinizi değiştirirken birkaç dakika kısa bir kesinti yaşayabilirsiniz. depolama. Kesintiden sonra, DB örneği çevrimiçi ancak Depolama optimizasyon durumundadır. Depolama optimizasyonu sırasında performans düşebilir.

İlk olarak, yanlış işleme baktığınızı unutmayın - depolama boyutunu değiştirmek istediğinizi ancak depolama türünü tanımlayan belgelere sahip olduğunuzu belirtirsiniz . Bu önemli bir ayrımdır: RDS, depolama boyutunu değiştirmek için bir kesinti yaşamayacağınızı, ancak depolama türünü değiştirmek için bir kesinti yaşayamayacağınızı önerir.

Süresi ve etkisi birkaç faktöre bağlı olacak olan depolama büyüklüğünü değiştirmek için düşük performans beklenir:

• RDS örnek türünüz
• Yapılandırma
  • Bu bakım sırasında gerçekleşecek mi?
  • Bu değişiklikler önce Multi-AZ kölenizde, sonra da yerine çalışmada gerçekleşecek mi?
• Mevcut veritabanı boyutu
• Aday veritabanı boyutu
• AWS bu talebi, istediğiniz saatte, istediğiniz uygunluk bölgesinde ve istediğiniz bölgede işleme koyma kapasitesi
• Motor tipi ( Amazon Aurora kullanıcıları için , depolama ilaveleri, 10 GB'lik artışlarla gerektiğinde RDS tarafından yönetiliyor, bu nedenle tartışma devam ediyor)

Bunu aklınızda tutarak, bunu kendiniz, ortamınızda ve şartlarınızda test ederek daha iyi hizmet alabilirsiniz. Aşağıdakileri denemeyi deneyin:

• Yeni bir RDS örneğini mevcut örneğinizin anlık görüntüsünden geri yükleme ve bu işlemi yeni klonda gerçekleştirme.
• Bu klonla:
  • Boyutu AWS'den farklı bir yük beklediğiniz günün farklı saatlerinde artırın.
  • Farklı boyutlarda artırın.
  • Multi-AZ ile deneyin. Gerçek kapalı kalma süreniz multi-AZ'yi etkinleştirmeme durumuna göre değişiyor mu bakın.
  • Bir bakım penceresi sırasında deneyin ve değişikliği hemen uygulayarak karşılaştırın.

Bu biraz daha pahalıya mal olacak (buna gerek kalmaz ... bunun çoğunu 1-3 örnek saatte yapabilirsiniz), ancak sayısız farklı RDS'deki deneyimlerimiz için pazarlık etmekten çok daha temiz bir cevap alacaksınız. ortamları.

Hala bir "ballpark" cevabı arıyorsanız, dakikalar içinde en azından performans düşmesini planlamanızı tavsiye ederim, yine ortamınıza ve yapılandırmanıza çok bağlı.

Başvuru için, son olarak bir Cumartesi öğleden sonra (EST) bir 40GB db.m1.small tipi örneğine 10GB eklemek için bu kesin işlemi uyguladım. Örnek, yaklaşık 17 dakika boyunca "değiştirme" durumunda kaldı. Değiştiren durumun, gerçek duruş süresini değil, operasyonun uygulanma süresini açıkladığını unutmayın . Gerçek örneğe ek değişiklikler uygulayamayacaksınız (yine de DB'nin kendisine erişebilseniz de) ve bu aynı zamanda herhangi bir performans düşüşünün gerçekleşmesini bekleyebileceğiniz süredir.

Yalnızca depolama boyutunu değiştirmeyi planlıyorsanız, kesinti beklenmedik değildir, ancak bu değişikliğin örnek tanımlayıcı / sınıfını veya depolama türünü değiştirme gibi diğer işlemlerle birlikte yapılması durumunda gerçekleşebileceğini unutmayın .

Yalnızca depolama boyutunu artırdığınızdan ve örnek türünü veya başka herhangi bir şeyi değiştirmeyeceğiniz için herhangi bir kesinti olmamalıdır, ancak işlem yapılırken 'düşük performans' olabilir.

Alıntı yaptığınız referans belirsizdir, çünkü değişen depolama boyutunu tartışırken aynı zamanda depolama türünü değiştirmeyi de tartışmaktadır. Bunun yerine buradaki tabloda 'Tahsis Edilen Saklama' bölümüne bakarsanız:

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

Sadece "Performans düşebilir" diyor ve bir kesinti ile ilgili hiçbir şey yok (bunun depolama türünü değiştirirken bazı durumlarda meydana geldiğini söylüyor) göreceksiniz.

Başvuru için, çalışma günü boyunca 15GB db.m3.medium MySQL veritabanının eu-west-1'de 20GB olması gerektiğinde, uygulamamın veritabanına olan bağlantısı kesildi. Ancak, okuma / yazma IOPS'lerinin her ikisi de sadece 20 dakikadan daha az bir sürede 400-700 / s'ye yükseldi, bu nedenle sanırım düşük performansa referanslar. Bu, hem tek AZ hem de çoklu AZ veritabanı örnekleri için rapor edildi. (Örnek, bundan biraz daha uzun bir süre 'değişiklik' olarak rapor edildi - yaklaşık 25 dakika.)

Doğal olarak, üretim db örneğinizde yapmadan önce üretim db'nizle aynı db örneğinde deneyebilirsiniz, böylece durumunuzu gerçekte yapmadan önce durumunuzda nasıl davrandığını güvenle görebilirsiniz.