Les instances Amazon RDS peuvent-elles être mises à niveau?
Pourrai-je basculer (je veux dire, mettre à niveau ou rétrograder) l'instance Amazon RDS en cas de besoin ou dois-je en créer une nouvelle et effectuer une migration?
Yes, les instances Amazon RDS peuvent être mises à niveau via la commande modify-db-instance. Il n'y a pas besoin de migration de données.
À partir de documentation Amazon RDS :
"Si vous n'êtes pas sûr de la quantité de CPU dont vous avez besoin, nous vous recommandons de commencer avec la classe d'instance de base de données db.m1.small et de surveiller l'utilisation du processeur avec le service CloudWatch d'Amazon. Si votre instance de base de données est liée au processeur, vous pouvez facilement mettre à niveau vers une base de données plus grande Classe d'instance utilisant la commande rds-modify-db-instance.
Amazon RDS effectuera la mise à niveau lors de la prochaine fenêtre de maintenance. Si vous souhaitez que la mise à niveau soit effectuée maintenant, plutôt que d'attendre la fenêtre de maintenance, spécifiez l'option --apply-immediat. Avertissement: la modification de la classe d'instance de base de données nécessite une brève panne de votre instance de base de données. "
RE: Outage Time : nous avons une instance RDS de SQL Server 2012 (lecteur non IOPS de 1 To), et allant d’un db.m1.xlarge à db.m3.xlarge (plus de CPU , moins $$) a entraîné un peu plus de 4 minutes d’immobilisation.
REMARQUE: Nous avons effectué la mise à niveau à partir de l'interface graphique de la console AWS et sélectionné "Appliquer immédiatement", mais il s'est écoulé 10 minutes avant le début de la panne. Le statut RDS indiquait "Modifying" immédiatement après le lancement de la mise à jour et restait ainsi pendant le temps d'attente et le temps d'indisponibilité.
J'espère que cela t'aides!
Greg
Je viens juste de passer d'une instance RDS moyenne à une grande quand nous avons été victimes d'un trafic inattendu (bon, non? :)). Depuis que nous avons une instance multi-AZ, nous étions en panne pendant 2-3 minutes. Dans la documentation d'Amazon, ils disent que le temps d'indisponibilité sera bref si vous avez une instance multi-AZ.
Pour tous les intéressés, nous venons de modifier une instance RDS (MySQL, 15 Go HD, reste de paramètres standard) en la passant de micro à petite. La période d'indisponibilité était de 5 minutes.
RE: Outage Time: nous venons de mettre à niveau Postgresql 9.3 en demandant immédiatement les modifications suivantes:
- mise à niveau de postgresql 9.3.3 à 9.3.6
- exemple redimensionner de m3.large à m3.2xlarge
- changement de type de stockage en IOPS provisionné
- extension de la mémoire de 200G à 500G (opération la plus coûteuse en temps)
Cela nous a pris presque 5 heures à compléter toute cette opération. La base de données contient environ 100 G de données au moment de la mise à niveau. Vous pouvez surveiller la progression de votre mise à niveau dans la section Events de la console RDS. Au cours de la mise à niveau, RDS prend quelques instantanés de sauvegarde. Vous pouvez surveiller leur progression dans la section Snapsnots.
Nous venons d'effectuer une mise à niveau de db.m3.large vers db.m3.xlarge avec 200 Go de données non IOPS exécutant SQL Server 2012. Le temps d'arrêt était d'environ 5 minutes.
La mise à niveau de MySQL RDS de db.t2.small vers db.t2.medium pour 25 Go de données a pris 6 minutes.
Oui, ils peuvent être mis à niveau. Instance RDS mise à niveau de SQL Server 2008 à SQL Server 2012 pour une taille d'instance d'environ 36 Go, classe db-m1-small, stockage 200 Go et sans IOPS ou Multi AZ. Il n'y avait pas de temps mort, ce processus prenait à peine 10 minutes.
Sur multi-az, il y aura un basculement, mais sinon, tout se déroulera normalement . Voici les données de chronologie de ma dernière version de type d'instance de base rétrogradée de r3.4xlarge à r3.2xlarge sur une version 32 Multi-Az configurée avec 3 To de disque (les données réelles sont seulement ~ 800G)
time (utc-8) eventMar 11 10:28 AM Finished applying modification to DB instance classMar 11 10:09 AM Multi-AZ instance failover completedMar 11 10:08 AM DB instance restartedMar 11 10:08 AM Multi-AZ instance failover started