Wie ändere ich die Größe eines Amazon Redshift-Clusters?

Kurzbeschreibung

Um die Größe des Clusters zu ändern, verwende entweder elastische Größenanpassung oder klassische Größenanpassung. Es hat sich bewährt, die elastische Größenanpassung zu verwenden, wenn der Cluster geeignet ist. Wenn der Cluster nicht qualifiziert ist, verwende die klassische Größenanpassung.

Lösung

Cluster-Eignung ermitteln

Hinweis: Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version der AWS CLI verwendest.

Um zu überprüfen, ob der Cluster für die elastische Größenanpassung in Frage kommt, führe den AWS-CLI-Befehl describe-node-configuration-options aus:

aws redshift describe-node-configuration-options --cluster-identifier example-cluster-id --action-type resize-cluster

Hinweis: Ersetze example-cluster-id durch die Cluster-ID.

Wenn der Cluster für die elastische Größenanpassung in Frage kommt, sieht die Ausgabe etwa wie folgt aus:

{
  "NodeConfigurationOptionList": [
    {
      "NodeType": "dc2.large",
      "NumberOfNodes": 2,
      "EstimatedDiskUtilizationPercent": 0.01
    },
    {
      "NodeType": "ra3.16xlarge",
      "NumberOfNodes": 2,
      "EstimatedDiskUtilizationPercent": 0.01
    }
  ]
}

Wenn der Cluster nicht für die elastische Größenanpassung in Frage kommt, sieht die Ausgabe etwa wie folgt aus:

{
  "NodeConfigurationOptionList": []
}

Betriebszeit reduzieren

Wenn du elastische Größenanpassung für einen Cluster mit demselben Knotentyp verwendest, erstellt der Vorgang keinen neuen Cluster und ist schnell abgeschlossen.

Wenn du die klassische Größenanpassung verwendest, hängt die Bearbeitungszeit von den folgenden Faktoren ab:

• Die Workload auf dem Quell-Cluster.
• Die Anzahl und Größe der Tabellen, die du vom Quell- zum Ziel-Cluster überträgst.
• Die Verteilung der Daten auf die Rechenknoten und Slices.
• Die Knotenkonfiguration in den Quell- und Ziel-Clustern.

Gehe wie folgt vor, um die Dauer einer klassischen Größenanpassung zu verkürzen:

• Migriere zu einem RA3-Knotentyp.
• Identifiziere und korrigiere schiefe Tabellen. Um schiefe Tabellen zu identifizieren, führe das Tabellen-Inspektorskript in AWS-Übungen aus. Weitere Informationen findest du unter table_inspector auf der GitHub-Website. Um schiefe Tabellen zu korrigieren, wähle einen geeigneten Verteilungsschlüssel.
• Entferne unbenutzte Tabellen. Um unbenutzte Tabellen zu identifizieren, führe das Skript der Zusammenfassung für ungescannte Tabellen in AWS-Übungen aus. Weitere Informationen findest du unter unscanned_table_summary auf der GitHub-Website.
  Hinweis: Die Zusammenfassung der ungescannten Tabelle zeigt nur den aktuellen Verlauf der letzten 2 bis 5 Tage. Verwende das Hilfsprogramm zur Persistenz von Systemobjekten, um Nutzungsdaten über einen längeren Zeitraum zu erfassen. Weitere Informationen findest du unter SystemTablePersistence auf der GitHub-Website.
• Identifiziere fehlende Tabellendaten. Verwende das AWS-Übungen-Skript missing_table_stats, um fehlende Tabellendaten zu identifizieren. Weitere Informationen findest du unter missing_table_stats auf der GitHub-Website. Führe dann den Befehl ANALYZE für diese Tabellen aus.

Weitere Informationen zur Leistungsoptimierung bei der Größenanpassung findest du unter Die 10 wichtigsten Techniken zur Leistungsoptimierung für Amazon Redshift. Um mit der Amazon Redshift-Konsole den Status des Größenanpassungsvorgangs zu überprüfen, wähle auf der Cluster-Detailseite die Registerkarte Status. Auf der Registerkarte Status werden die durchschnittliche Übertragungsrate, die verstrichene Zeit und die verbleibende Zeit angezeigt.

Größenanpassung des Clusters

Verwende elastische Größenanpassung, um den Cluster-Knotentyp, die Anzahl der Knoten oder beides zu ändern.

Verwende die klassische Größenanpassung, wenn die elastische Größenanpassung die Änderung der Cluster-Größe oder des Knotens nicht unterstützt.

Problembehebung bei der Größenanpassung

Während einer Größenanpassung kann die Tabelle in ihrer Größe abnehmen oder zunehmen. Weitere Informationen findest du unter Warum verbraucht eine Tabelle in einem bereitgestellten Cluster in Amazon Redshift mehr oder weniger Festplattenspeicher als erwartet?

Wenn das Cluster in der AWS CLI den Status NONE hat, stellt Amazon Redshift den Ziel-Cluster immer noch bereit. Der Ziel-Cluster wird erst kopiert, wenn die Bereitstellungsphase abgeschlossen ist. Nachdem Amazon Redshift den Ziel-Cluster bereitgestellt hat, ändert sich der Status zu IN_PROGRESS.

Wenn die AWS CloudFormation StackSets nicht skaliert werden und du eine interne Fehlermeldung erhältst, überprüfe, ob der Cluster für eine elastische Größenanpassung in Frage kommt. Die Fehlermeldung ist ähnlich wie: „An internal error has occurred. Please try your query again at a later time.“ Dies liegt daran, dass ein CloudFormation-Stack elastische Größenanpassung verwendet und Classic:False standardmäßig gesetzt ist.

Wenn du die Fehlermeldung „Please choose a larger target cluster“ erhältst, passen die Daten nicht in den Ziel-Cluster. Passe die Größe des Amazon Redshift-Clusters mit mehr Knoten oder einem anderen Knotentyp an.

Um einen klassischen Größenanpassungsvorgang abzubrechen, bevor der Vorgang abgeschlossen ist, wähle in der Amazon Redshift-Konsole in der Cluster-Liste die Option Größenanpassung abbrechen.

Abrechnung für Cluster mit geänderter Größe

Während der Größenanpassung stellt dir AWS die Cluster in Rechnung, die dir zur Verfügung stehen. Während des Größenanpassungsvorgangs stellt dir AWS beispielsweise die Quellkonfiguration in Rechnung. Nachdem die Größenanpassung abgeschlossen ist, stellt dir AWS die Quellkonfiguration nicht mehr in Rechnung. Die Abrechnung für die Zielkonfiguration beginnt, sobald sich der Cluster-Status zu Verfügbar ändert.

Wenn du die Größe kleinerer Knotentypen wie Large oder Xlarge zu größere Knotentypen wie 8xlarge änderst, benötigt der Cluster mehr Speicherplatz pro Knoten. Je mehr Speicherplatz du pro Knoten hast, desto mehr Metadaten werden geschrieben, wenn du einen COMMIT-Vorgang ausführst. Daher sind die Grundkosten für einen einzelnen COMMIT-Vorgang bei größeren Knoten höher. Wenn du mehrere kleine COMMIT-Vorgänge gleichzeitig ausführst, kann es zu Leistungseinbußen kommen. Um die Leistung zu verbessern, gruppiere mehrere Änderungen in einem einzigen COMMIT-Vorgang.

Wenn du Reserved Instances gekauft hast, hängt die Abrechnung von der geänderten Cluster-Konfiguration, den reservierten Knotentypen und der Anzahl der reservierten Knoten ab. Weitere Informationen findest du unter So funktionieren reservierte Knoten.

Ähnliche Informationen

Behebung von Verbindungsproblemen in Amazon Redshift

Erstellung hochwertiger Benchmark-Tests für Amazon Redshift mit SQLWorkbench und psql

Cluster-Vorgänge