27 votes

Temps d'arrêt pour la mise à niveau d'une instance AWS RDS

J'ai quelques questions concernant la mise à niveau de l'instance RDS.

  1. Quel est le temps d'arrêt lors de la mise à niveau de l'instance de disons petite à grande. Le temps d'arrêt est-il relativement similaire lorsque vous changez de type d'instance (small, large, xlarge) ou existe-t-il des facteurs déterminants tels que la taille de la base de données qui modifient le timing ?
  2. Quelqu'un peut-il partager une technique permettant de mettre à niveau le type d'instance en évitant le temps d'arrêt en utilisant RDS ? Est-ce même possible avec RDS ? Il n'est pas nécessaire d'entrer dans les détails, mais seulement de donner des explications générales.
  3. Y a-t-il des temps morts lorsque vous allouez plus d'espace disque ?

24voto

Dan Grossman Points 31514

Je ne pense pas qu'il s'agisse d'une question sur le sujet pour StackOverflow, mais j'aimerais quand même avoir quelques informations :

  1. C'est important et cela dépend de la taille de la base de données. Il m'est arrivé que cela prenne une heure ou plus. La création de snapshots, la restauration à partir de snapshots et la création de multi-zones ont également pris environ deux heures auparavant.

  2. Cela dépend de la façon dont vous avez configuré les choses maintenant. Si vous avez déjà activé Multi-AZ, une mise à niveau de l'instance se produira sur l'esclave, puis un basculement se produira et le nouvel esclave sera mis à jour. Il en résulte environ 1 ou 2 minutes de temps d'arrêt réel. La mise à niveau de l'instance sur l'esclave prend généralement entre 10 et 20 minutes, mais il n'y a pas de temps d'arrêt dans cette configuration. Notez que lorsqu'il effectue le basculement, Amazon effectue un échange de DNS en interne afin que votre point de terminaison RDS pointe vers la bonne machine. Il se peut donc que vous deviez redémarrer vos processus web qui pointent vers la base de données afin qu'ils se reconnectent à la base de données et récupèrent la nouvelle adresse IP à partir d'une nouvelle recherche DNS.

8voto

Alastair Points 1492

db.t1.micro > db.m1.small : 8m30s

Engine:    mysql
Storage:    6GiB
Backups:    Yes
Multi A-Z:  No

La taille et le type de la base de données semblent avoir une incidence importante sur le temps d'arrêt.

7voto

DAiki Points 61

1. D'après mon expérience personnelle, il faut un peu moins d'une heure, pour être précis 57 minutes pour une instance de 15 Go pour passer de petite à grande. Je ne m'attendais pas à ce que ce soit aussi long pour être honnête. mise à jour : je viens d'apprendre que le fait de passer à une sauvegarde ponctuelle avant la mise à niveau accélère considérablement le processus.

2, je dirais que créer MULTI AZ avant de faire la mise à jour ferait l'affaire, en espérant que cela n'entraîne pas de temps d'arrêt. La question est de savoir s'ils permettent de mettre à niveau l'un sans l'autre...

3, oui, mais je ne suis pas sûr à 100%.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X