Tempo di inattività per aumentare lo spazio di archiviazione RDS AWS?

Sto cercando di aumentare la memoria di due istanze RDS (solo lo spazio di memoria allocato, non il tipo di istanza o altri parametri). La documentazione su https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html#USER_PIOPS.ModifyingExisting suggerisce:

È possibile passare dallo storage standard allo storage IOPS con provisioning o dallo storage IOPS con provisioning allo storage standard, nonché aumentare lo storage, con tempi di inattività ridotti.

Definirei sicuramente una finestra di manutenzione prima di eseguire la modifica. Ma la documentazione sembra un po 'vaga in questo settore. Per qualcuno che potrebbe averlo fatto prima, che cosa è "poco o nessun tempo morto"? Posso aspettarmi 5 secondi o è più simile a 5 minuti?

Aggiornamento luglio 2019:

Ho aggiornato il link alla documentazione AWS corretta e aggiornata (che è stata interrotta). La documentazione più recente ha un blurb che aiuta a rispondere anche alla domanda originale:

Nella maggior parte dei casi, il ridimensionamento della memoria non richiede alcuna interruzione e non peggiora le prestazioni del server. Dopo aver modificato le dimensioni di archiviazione per un'istanza DB, lo stato dell'istanza DB è Ottimizzazione archiviazione. L'istanza DB è completamente operativa dopo una modifica della memoria. Tuttavia, non è possibile apportare ulteriori modifiche alla memoria per sei ore o mentre lo stato dell'istanza DB è ottimizzato per la memorizzazione, a seconda di quale sia il periodo più lungo.

Tuttavia, un caso speciale è se si dispone di un'istanza DB di SQL Server e non si è modificata la configurazione di archiviazione da novembre 2017. In questo caso, è possibile che si verifichi una breve interruzione di alcuni minuti quando si modifica l'istanza DB per aumentare l'allocazione Conservazione. Dopo l'interruzione, l'istanza DB è online ma nello stato di ottimizzazione dell'archiviazione. Le prestazioni potrebbero essere ridotte durante l'ottimizzazione dell'archiviazione.

Innanzitutto, tieni presente che potresti osservare un'operazione errata: descrivi che desideri modificare le dimensioni di archiviazione , ma hai citato la documentazione che descrive il tipo di archiviazione . Questa è una distinzione importante: RDS avvisa che non si verificherà un'interruzione per modificare le dimensioni di archiviazione, ma che si verificherà un'interruzione per modificare il tipo di archiviazione.

Aspettati prestazioni degradate per la modifica delle dimensioni di archiviazione, la cui durata e impatto dipenderanno da diversi fattori:

• Il tuo tipo di istanza RDS
• Configurazione
  • Questo accadrà durante la manutenzione?
  • Queste modifiche verranno apportate prima sullo slave Multi-AZ e poi sul failover?
• Dimensione corrente del database
• Dimensione del database dei candidati
• Capacità di AWS di gestire questa richiesta all'ora del giorno richiesta, nella zona di disponibilità richiesta, nella regione richiesta
• Tipo di motore (per gli utenti di Amazon Aurora , le aggiunte di archiviazione sono gestite da RDS secondo necessità con incrementi di 10 GB, quindi questa discussione è controversa)

Con questo in mente, verrai servito meglio testandolo tu stesso, nel tuo ambiente e alle tue condizioni. Prova a sperimentare quanto segue:

• Ripristino di una nuova istanza RDS da un'istantanea dell'istanza esistente ed esecuzione di questa operazione sul nuovo clone.
• Con questo clone:
  • Aumenta le dimensioni in diversi momenti della giornata, quando ti aspetteresti un carico diverso su AWS.
  • Aumentare a diverse dimensioni.
  • Provalo con multi-AZ. Verifica se i tempi di inattività reali cambiano rispetto al non abilitare la multi-AZ.
  • Provalo durante una finestra di manutenzione e confrontalo con l'applicazione della modifica immediatamente.

Questo costerà un po 'di più (non è necessario ... potresti fare la maggior parte di questo in 1-3 ore di istanza), ma otterrai una risposta molto più pulita rispetto a spacciare per le nostre esperienze in una miriade di RDS diversi ambienti.

Se stai ancora cercando una risposta "ballpark", consiglierei di pianificare almeno il degrado delle prestazioni in termini di minuti, non di secondi - ancora una volta molto dipendente dal tuo ambiente e dalla tua configurazione.

Per riferimento, di recente ho applicato questa operazione esatta per aggiungere 10 GB a un'istanza di tipo db.m1.sm di 40 GB di sabato pomeriggio (in EST). L'istanza è rimasta in uno stato di "modifica" per circa 17 minuti. Si noti che lo stato di modifica non descrive i tempi di inattività reali, ma piuttosto la durata in cui l'operazione viene applicata . Non sarai in grado di applicare ulteriori modifiche all'istanza effettiva (anche se puoi comunque accedere al DB stesso) e questa è anche la durata in cui puoi aspettarti che si verifichi un peggioramento delle prestazioni.

Se stai solo pensando di modificare le dimensioni della memoria, un'interruzione è imprevista, ma tieni presente che può verificarsi se questa modifica viene eseguita insieme ad altre operazioni come la modifica dell'identificatore / classe dell'istanza o del tipo di archiviazione.

Poiché si stanno solo aumentando le dimensioni dell'archiviazione e non si modifica il tipo di istanza o qualsiasi altra cosa, non dovrebbero esserci tempi di inattività, ma potrebbero verificarsi "prestazioni degradate" durante l'operazione.

Il riferimento che hai citato è ambiguo perché sta discutendo di cambiare il tipo di archiviazione contemporaneamente a discutere della modifica delle dimensioni di archiviazione. Se invece guardi 'Allocated Storage' nella tabella qui:

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

vedrai che dice solo "Le prestazioni potrebbero essere ridotte" e nulla di un'interruzione (che dice che si verifica in alcuni casi quando si cambia tipo di archiviazione).

Per riferimento, durante la modifica di un database MySQL db.m3.medium da 15 GB a 20 GB in eu-west-1 durante la giornata lavorativa, la connettività della mia app al database è stata ininterrotta. Tuttavia, gli IOPS in lettura / scrittura sono entrambi aumentati a 400-700 / s per poco meno di 20 minuti, quindi suppongo che i riferimenti a prestazioni degradate. Questo è stato segnalato per istanze di database sia AZ singole che AZ multiple. (L'istanza è stata segnalata come "modifica" per un po 'più di questo - circa 25 minuti.)

Naturalmente puoi provarlo su un'istanza di db identica al tuo db di produzione prima di farlo sull'istanza di db di produzione in modo da poter vedere in sicurezza come si comporta nella tua situazione prima di farlo sul serio.