Temps d'arrêt pour augmenter le stockage AWS RDS?

Je cherche à augmenter le stockage de deux instances RDS (juste l'espace de stockage alloué, pas le type d'instance ou d'autres paramètres). La documentation à https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html#USER_PIOPS.ModifyingExisting suggère:

Vous pouvez passer du stockage standard au stockage IOPS provisionné, ou du stockage IOPS provisionné au stockage standard, ainsi qu'augmenter le stockage, avec peu ou pas de temps d'arrêt.

Je planifierais certainement une fenêtre de maintenance avant d'effectuer le changement. Mais la documentation semble un peu vague dans ce domaine. Pour quelqu'un qui aurait pu le faire auparavant, qu'est-ce que "peu ou pas de temps d'arrêt"? Puis-je m'attendre à 5 secondes ou est-ce plus comme 5 minutes?

Mise à jour juillet 2019:

J'ai mis à jour le lien vers la documentation AWS correcte et mise à jour (qui était cassée). La documentation la plus récente comporte un texte explicatif qui permet également de répondre à la question d'origine:

Dans la plupart des cas, la mise à l'échelle du stockage ne nécessite aucune interruption et ne dégrade pas les performances du serveur. Après avoir modifié la taille de stockage d'une instance de base de données, l'état de l'instance de base de données est Optimisation du stockage. L'instance de base de données est pleinement opérationnelle après une modification du stockage. Cependant, vous ne pouvez pas apporter de modifications de stockage supplémentaires pendant six heures ou pendant que l'état de l'instance de base de données est optimisation du stockage, la durée la plus longue étant retenue.

Cependant, un cas particulier se présente si vous avez une instance de base de données SQL Server et n'avez pas modifié la configuration de stockage depuis novembre 2017. Dans ce cas, vous risquez de subir une courte interruption de quelques minutes lorsque vous modifiez votre instance de base de données pour augmenter l'allocation allouée. espace de rangement. Après la panne, l'instance de base de données est en ligne mais à l'état d'optimisation du stockage. Les performances peuvent être dégradées lors de l'optimisation du stockage.

Tout d'abord, notez que vous envisagez peut-être l'opération incorrecte - vous décrivez que vous souhaitez modifier la taille de stockage , mais avez cité la documentation décrivant le type de stockage . Il s'agit d'une différence importante: RDS vous informe que vous ne subirez pas d'interruption pour changer la taille du stockage, mais que vous subirez une interruption pour changer le type de stockage.

Attendez-vous à des performances dégradées pour changer la taille du stockage, dont la durée et l'impact dépendront de plusieurs facteurs:

• Votre type d'instance RDS
• Configuration
  • Cela se produira-t-il pendant la maintenance?
  • Ces changements se produiront-ils d'abord sur votre esclave Multi-AZ, puis basculeront-ils?
• Taille actuelle de la base de données
• Taille de la base de données des candidats
• Capacité AWS pour traiter cette demande à l'heure demandée, dans la zone de disponibilité souhaitée, dans la région souhaitée
• Type de moteur (pour les utilisateurs d' Amazon Aurora , les ajouts de stockage sont gérés par RDS selon les besoins par incréments de 10 Go, donc cette discussion est théorique)

Dans cet esprit, vous seriez mieux servi en testant vous-même, dans votre environnement et selon vos conditions. Essayez d'expérimenter les éléments suivants:

• Restauration d'une nouvelle instance RDS à partir d'un instantané de votre instance existante et exécution de cette opération sur le nouveau clone.
• Avec ce clone:
  • Augmentez la taille à différents moments de la journée, lorsque vous vous attendez à une charge différente sur AWS.
  • Augmentez à différentes tailles.
  • Essayez-le avec multi-AZ. Vérifiez si votre temps d'arrêt réel change par rapport à la non-activation de la multi-AZ.
  • Essayez-le pendant une fenêtre de maintenance et comparez-le avec l'application immédiate de la modification.

Cela coûtera un peu plus (ce n'est pas nécessaire ... vous pourriez faire la plupart de cela en 1 à 3 heures), mais vous obtiendrez une réponse beaucoup plus nette que le colportage pour nos expériences dans une myriade de différents RDS environnements.

Si vous êtes toujours à la recherche d'une réponse "approximative", je vous conseille de prévoir au moins une dégradation des performances en quelques minutes, pas en quelques secondes - encore une fois, cela dépend beaucoup de votre environnement et de votre configuration.

Pour référence, j'ai récemment appliqué cette opération exacte pour ajouter 10 Go à une instance de type 40 Go db.m1.small un samedi après-midi (en EST). L'instance est restée dans un état "modificateur" pendant environ 17 minutes. Notez que l'état de modification ne décrit pas les temps d'arrêt réels, mais plutôt la durée pendant laquelle l'opération est appliquée . Vous ne pourrez pas appliquer de modifications supplémentaires à l'instance réelle (bien que vous puissiez toujours accéder à la base de données elle-même) et c'est également la durée pendant laquelle vous pouvez vous attendre à une dégradation des performances.

Si vous prévoyez uniquement de modifier la taille du stockage, une panne est inattendue, mais notez qu'elle peut se produire si cette modification est effectuée conjointement avec d' autres opérations telles que la modification de l'identificateur / classe d'instance ou du type de stockage.

Comme vous n'augmentez que la taille du stockage et ne modifiez pas le type d'instance ou quoi que ce soit d'autre, il ne devrait pas y avoir de temps d'arrêt, mais il pourrait y avoir des «performances dégradées» pendant l'exécution de l'opération.

La référence que vous avez citée est ambiguë car elle traite de la modification du type de stockage en même temps que de la modification de la taille de stockage. Si vous regardez à la place «Stockage alloué» dans le tableau ici:

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

vous verrez qu'il indique uniquement "Les performances peuvent être dégradées" et rien à propos d'une panne (qui, selon lui, se produit dans certains cas lors du changement de type de stockage).

Pour référence, lors de la modification d'une base de données MySQL de 15 Go db.m3.medium à 20 Go dans eu-west-1 pendant la journée de travail, la connectivité de mon application à la base de données n'a pas été interrompue. Cependant, les IOPS en lecture / écriture ont tous deux augmenté entre 400 et 700 / s pendant un peu moins de 20 minutes, d'où les références à des performances dégradées, je suppose. Cela a été signalé pour les instances de base de données mono-AZ et multi-AZ. (L'instance a été signalée comme «modifiant» pendant un peu plus longtemps que cela - environ 25 minutes.)

Naturellement, vous pouvez l'essayer sur une instance de base de données identique à votre base de données de production avant de le faire sur votre instance de base de données de production afin que vous puissiez voir en toute sécurité comment il se comporte dans votre situation avant de le faire pour de vrai.