Ausfallzeiten zur Erhöhung des AWS RDS-Speichers?


22

Ich möchte den Speicher für zwei RDS-Instanzen erhöhen (nur den zugewiesenen Speicherplatz, nicht den Instanztyp oder andere Parameter). In der Dokumentation unter https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html#USER_PIOPS.ModifyingExisting wird Folgendes vorgeschlagen:

Sie können vom Standardspeicher zum bereitgestellten IOPS-Speicher oder vom bereitgestellten IOPS-Speicher zum Standardspeicher wechseln und den Speicherplatz ohne oder mit geringen Ausfallzeiten erhöhen.

Ich würde definitiv ein Wartungsfenster einplanen, bevor ich die Änderung vornehme. Aber die Dokumentation scheint in diesem Bereich ein wenig vage zu sein. Was bedeutet für jemanden, der dies möglicherweise schon einmal getan hat, "wenig bis keine Ausfallzeit"? Kann ich mit 5 Sekunden rechnen oder sind es eher 5 Minuten?

Update Juli 2019:

Ich habe den Link zur korrekten und aktualisierten AWS-Dokumentation (die fehlerhaft war) aktualisiert. Die neuere Dokumentation enthält einen Klappentext, mit dem auch die ursprüngliche Frage beantwortet werden kann:

In den meisten Fällen ist für die Skalierung des Speichers kein Ausfall erforderlich, und die Leistung des Servers wird nicht beeinträchtigt. Nachdem Sie die Speichergröße für eine DB-Instanz geändert haben, lautet der Status der DB-Instanz Speicheroptimierung. Die DB-Instanz ist nach einer Speicheränderung voll funktionsfähig. Sie können jedoch keine weiteren Speichermodifikationen vornehmen, entweder für sechs Stunden oder während der Status der DB-Instanz die Speicheroptimierung ist, je nachdem, welcher Zeitraum länger ist.

Ein Sonderfall ist jedoch, wenn Sie über eine SQL Server-DB-Instanz verfügen und die Speicherkonfiguration seit November 2017 nicht geändert haben. In diesem Fall kann es zu einem kurzen Ausfall von einigen Minuten kommen, wenn Sie Ihre DB-Instanz ändern, um die zugewiesene zu erhöhen Lager. Nach dem Ausfall ist die DB-Instanz online, befindet sich jedoch im Zustand Speicheroptimierung. Die Leistung kann während der Speicheroptimierung beeinträchtigt werden.

Antworten:


21

Beachten Sie zunächst, dass Sie auf dem falschen Betrieb suchen können - Sie beschreiben , die Sie ändern wollen , Speichergröße , sondern haben Dokumentation zitiert Speicher beschreibt Art . Dies ist eine wichtige Einschränkung: RDS weist darauf hin, dass bei einer Änderung der Speichergröße kein Ausfall auftritt, bei einer Änderung des Speichertyps jedoch ein Ausfall.

Erwarten Sie eine verminderte Leistung, wenn Sie die Speichergröße ändern, deren Dauer und Auswirkungen von mehreren Faktoren abhängen:

  • Ihr RDS-Instanztyp
  • Aufbau
    • Tritt dies während der Wartung auf?
    • Treten diese Änderungen zuerst auf Ihrem Multi-AZ-Slave und dann auf dem Failover auf?
  • Aktuelle Datenbankgröße
  • Größe der Kandidatendatenbank
  • AWS-Kapazität, um diese Anfrage zu Ihrer gewünschten Tageszeit in Ihrer gewünschten Verfügbarkeitszone in Ihrer gewünschten Region zu bearbeiten
  • Modultyp (für Amazon Aurora-Benutzer werden Speicherzusätze nach Bedarf in Schritten von 10 GB von RDS verwaltet. Diese Diskussion ist daher umstritten.)

In diesem Sinne ist es besser, wenn Sie dies selbst, in Ihrer Umgebung und zu Ihren Bedingungen testen. Probieren Sie Folgendes aus:

  • Wiederherstellen einer neuen RDS-Instanz aus einem Snapshot Ihrer vorhandenen Instanz und Ausführen dieses Vorgangs für den neuen Klon.
  • Mit diesem Klon:
    • Erhöhen Sie die Größe zu verschiedenen Tageszeiten, wenn Sie eine andere Auslastung von AWS erwarten würden.
    • Auf verschiedene Größen erhöhen.
    • Probieren Sie es mit Multi-AZ. Prüfen Sie, ob sich Ihre tatsächliche Ausfallzeit im Vergleich zur Nichtaktivierung von Multi-AZ ändert.
    • Probieren Sie es während eines Wartungsfensters aus und vergleichen Sie es mit dem sofortigen Übernehmen der Änderung.

Dies wird ein bisschen mehr kosten (es muss nicht ... Sie könnten das meiste in 1-3 Instanzenstunden erledigen), aber Sie werden eine viel sauberere Antwort erhalten, als für unsere Erfahrungen in einer Vielzahl von verschiedenen RDS zu hausieren Umgebungen.

Wenn Sie immer noch nach einer Antwort auf Ihre Frage suchen, empfehle ich, zumindest Leistungseinbußen im Bereich von Minuten und nicht von Sekunden zu planen - wiederum sehr abhängig von Ihrer Umgebung und Konfiguration.

Als Referenz habe ich kürzlich genau diese Operation angewendet, um einer Instanz vom Typ db.m1.small mit 40 GB an einem Samstagnachmittag (in EST) 10 GB hinzuzufügen. Die Instanz blieb ungefähr 17 Minuten lang in einem "Änderungs" -Zustand. Beachten Sie, dass der Änderungsstatus nicht die tatsächliche Ausfallzeit beschreibt, sondern die Dauer, für die der Vorgang ausgeführt wird . Sie können keine zusätzlichen Änderungen an der tatsächlichen Instanz vornehmen (obwohl Sie immer noch auf die Datenbank selbst zugreifen können). Dies ist auch die Zeitdauer, für die Leistungseinbußen zu erwarten sind.

Wenn Sie nur vorhaben, die Speichergröße zu ändern, ist ein Ausfall unerwartet. Beachten Sie jedoch, dass er auftreten kann, wenn diese Änderung in Verbindung mit anderen Vorgängen wie dem Ändern der Instanz-ID / Klasse oder des Speichertyps vorgenommen wird.


Der letzte Absatz ist so ziemlich das, wonach ich gesucht habe. Das hilft sehr. Vielen Dank!
Andy Shinn

3
Ich bin über eine Stunde für das Hinzufügen von 10 GB zu einer 10 GB m3.xlarge DB um 3 Uhr morgens, wenn es kaum Verkehr gibt.
Neo

2
Ein weiterer Datenpunkt bestätigt ~ linear. Es dauerte 2 Stunden und 50 Minuten, um 100 G zu einer 300 G DB hinzuzufügen.
Joan Smith

2
Das Erhöhen der 10G-Kapazität auf 100G-Kapazität dauerte für mich auf einer db.t2.small mit General Purpose (SSD) und MultiAZ nur 23 Minuten. Beachten Sie auch, wenn Sie die Größe erhöhen, weil die Datenbank bereits VOLL ist, bleibt sie funktionsunfähig, bis der Vorgang abgeschlossen ist.
Davur

1
Das Erhöhen des PIOPS-Speichers von 100 auf 200 GB unter Last um 10 Uhr morgens dauerte etwa 30 Minuten und hatte keinen signifikanten Einfluss auf den Durchsatz / die Latenz. (Das Lesen / Schreiben von IOPS nahm während dieser Zeit erheblich zu.)
Taylor Hughes,

7

Da Sie nur die Speichergröße erhöhen und den Instanztyp oder etwas anderes nicht ändern, sollte es keine Ausfallzeit geben, aber während des Vorgangs kann es zu Leistungseinbußen kommen.

Der von Ihnen angegebene Verweis ist nicht eindeutig, da er das Ändern des Speichertyps gleichzeitig mit dem Ändern der Speichergröße behandelt. Wenn Sie stattdessen in der folgenden Tabelle auf "Zugewiesener Speicher" schauen:

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

Sie werden feststellen, dass nur die Meldung "Leistung kann beeinträchtigt sein" und nichts über einen Ausfall (der in einigen Fällen beim Wechseln des Speichertyps auftritt) angezeigt wird.

Als Referenz wurde die Verbindung meiner App zur Datenbank nicht unterbrochen, als eine MySQL-Datenbank mit 15 GB (db.m3.medium) im Laufe des Arbeitstages auf 20 GB (eu-west-1) geändert wurde. Die Lese- / Schreib-IOPS stiegen jedoch beide für knapp 20 Minuten auf 400-700 / s, weshalb ich davon ausgehe, dass die Leistung nachlässt. Dies wurde sowohl für Einzel-AZ- als auch für Multi-AZ-Datenbankinstanzen gemeldet. (Die Instanz wurde für etwas länger als dies als "modifizierend" gemeldet - ungefähr 25 Minuten.)

Natürlich können Sie es auf einer Datenbankinstanz ausprobieren, die mit Ihrer Produktionsdatenbank identisch ist, bevor Sie es auf Ihrer Produktionsdatenbankinstanz ausführen, damit Sie sicher feststellen können, wie es sich in Ihrer Situation verhält, bevor Sie es in der Realität ausführen.


1
Das Ändern des Speichertyps (Magnetic <-> gp2 / Provisioned IOPS) führt zu einem Ausfall. Das Anwachsen eines Volumes, das Ändern von mit gp2 <-> bereitgestellten IOPS oder das Anpassen von bereitgestellten IOPS sollte nicht zu einem Ausfall führen. Sie können ein Volume nicht verkleinern.
Notpeter
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.