Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Verwalten von Performance und Skalierung für einen Aurora-DB-Cluster
Für die Verwaltung von Performance und Skalierung von Aurora DB-Clustern und DB-Instances stehen Ihnen folgende Möglichkeiten zur Verfügung:
Themen
Speicherskalierung
Der Aurora-Speicher wird automatisch mit den Daten in Ihrem Cluster-Volume skaliert. Wenn Ihre Daten zunehmen, wird Ihr Cluster-Volume-Speicher bis zu einem Maximum von 128 Tebibytes (TiB) oder 64 TiB erweitert. Die maximale Größe hängt von der Version der DB-Engine ab. Informationen dazu, welche Datentypen im Cluster-Volume enthalten sind, finden Sie unter Amazon Aurora Aurora-Speicher. Weitere Informationen zur maximalen Größe für eine bestimmte Version finden Sie unter Amazon Aurora-Größenbeschränkungen.
Die Größe Ihres Cluster-Volumes wird stündlich überprüft, um die Kosten für Ihren Speicherplatz zu bestimmen. Informationen zu den Preisen finden Sie in der Aurora-Preisliste
Obwohl ein Aurora-Cluster-Volume in der Größe auf viele Tebibyte skaliert werden kann, wird nur der Speicherplatz berechnet, den Sie auf dem Volume verwenden. Der Mechanismus zur Bestimmung des fakturierten Speicherplatzes hängt von der Version Ihres Aurora-Clusters ab.
-
Wenn Aurora-Daten aus dem Cluster-Volume entfernt werden, verringert sich der gesamte fakturierte Speicherplatz um einen entsprechenden Betrag. Dieses dynamische Größenanpassungsverhalten tritt auf, wenn zugrunde liegende Tabellenbereiche gelöscht oder neu organisiert werden, damit sie weniger Speicherplatz benötigen. So können Sie Speicherkosten senken, indem Sie Tabellen und Datenbanken löschen, die Sie nicht mehr benötigen. Die dynamische Größenanpassung gilt für bestimmte Aurora-Versionen. Im Folgenden werden die Aurora-Versionen aufgeführt, bei denen die Größe des Cluster-Volumes beim Entfernen von Daten dynamisch geändert wird:
Datenbank-Engine Versionen mit dynamischer Größenänderung Aurora My SQL -
Version 3 (kompatibel mit My SQL 8.0): alle unterstützten Versionen
-
Version 2 (kompatibel mit My SQL 5.7): 2.11 und höher
Aurora Postgret SQL Alle unterstützten Versionen Aurora Serverless v2 Alle unterstützten Versionen Aurora Serverless v1 Alle unterstützten Versionen -
-
In Aurora-Versionen, die niedriger sind als die in der vorherigen Liste aufgeführten, kann das Cluster-Volume Speicherplatz wiederverwenden, der beim Entfernen von Daten frei wird, aber das Volume selbst nimmt nie an Größe ab.
-
Diese Funktion wird schrittweise in den AWS Regionen bereitgestellt, in denen Aurora verfügbar ist. Abhängig von der Region, in der sich Ihr Cluster befindet, ist diese Funktion möglicherweise noch nicht verfügbar.
Die dynamische Größenanpassung gilt für Operationen, bei denen Tabellenbereiche innerhalb des Cluster-Volumes physisch entfernt oder in der Größe geändert werden. Somit gilt sie für SQL Aussagen wieDROP TABLE, DROP DATABASETRUNCATE TABLE, undALTER TABLE ... DROP PARTITION. Sie gilt nicht für das Löschen von Zeilen mit der DELETE-Anweisung. Wenn Sie eine große Anzahl von Zeilen aus einer Tabelle löschen, können Sie die Aurora SQL OPTIMIZE TABLE My-Anweisung ausführen oder anschließend die Aurora SQL pg_repack Postgre-Erweiterung verwenden, um die Tabelle neu zu organisieren und die Größe des Cluster-Volumes dynamisch zu ändern.
Für Aurora My SQL gelten die folgenden Überlegungen:
-
Nachdem Sie Ihren DB-Cluster auf eine DB-Engine-Version aktualisiert haben, die dynamische Größenänderung unterstützt, und wenn die Funktion in dieser speziellen Version aktiviert ist AWS-Region, kann jeder Speicherplatz, der später durch bestimmte SQL Anweisungen, wie z. B., freigegeben wird
DROP TABLE, zurückgewonnen werden.Wenn die Funktion in einem bestimmten Bereich explizit deaktiviert ist AWS-Region, ist der Speicherplatz möglicherweise nur wiederverwendbar — und nicht zurückforderbar —, selbst in Versionen, die dynamische Größenänderung unterstützen.
Die Funktion wurde zwischen November 2020 und März 2022 für bestimmte DB-Engine-Versionen (1.23.0—1.23.4, 2.09.0—2.09.3 und 2.10.0) aktiviert und ist in allen nachfolgenden Versionen standardmäßig aktiviert.
-
Eine Tabelle wird intern in einem oder mehreren zusammenhängenden Fragmenten unterschiedlicher Größe gespeichert. Während der Ausführung von
TRUNCATE TABLEVorgängen ist der Speicherplatz, der dem ersten Fragment entspricht, wiederverwendbar und kann nicht zurückgewonnen werden. Andere Fragmente können zurückgewonnen werden. Während desDROP TABLEBetriebs kann Speicherplatz, der dem gesamten Tablespace entspricht, zurückgewonnen werden. -
Der
innodb_file_per_tableParameter beeinflusst, wie der Tabellenspeicher organisiert ist. Wenn Tabellen Teil des System-Tablespace sind, wird durch das Löschen der Tabelle die Größe des System-Tablespace nicht verringert. Stellen Sie daher sicher, dass Sie für Aurora My SQL DB-Cluster auf 1 setzeninnodb_file_per_table, um die dynamische Größenänderung voll auszunutzen. -
In Version 2.11 und höher wird der temporäre InnoDB-Tablespace gelöscht und beim Neustart neu erstellt. Dadurch wird der vom temporären Tabellenbereich belegte Speicherplatz für das System freigegeben und die Größe des Cluster-Volumes anschließend geändert. Um die dynamische Größenänderungsfunktion in vollem Umfang nutzen zu können, empfehlen wir Ihnen, Ihren DB-Cluster auf Version 2.11 oder höher zu aktualisieren.
Anmerkung
Mit der Funktion zur dynamischen Größenänderung wird Speicherplatz nicht sofort zurückgewonnen, wenn Tabellen in Tablespaces gelöscht werden, sondern schrittweise mit einer Geschwindigkeit von etwa 10 TB pro Tag. Speicherplatz im System-Tablespace wird nicht zurückgewonnen, da der System-Tablespace niemals entfernt wird. Nicht zurückgewonnener freier Speicherplatz in einem Tabellenraum wird wiederverwendet, wenn ein Vorgang Speicherplatz in diesem Tabellenraum benötigt. Die dynamische Größenanpassungsfunktion kann Speicherplatz nur dann zurückgewinnen, wenn sich der Cluster in einem verfügbaren Zustand befindet.
Sie können überprüfen, wie viel Speicherplatz ein Cluster verwendet, indem Sie die VolumeBytesUsed Metrik in überwachen. CloudWatch Weitere Informationen zu Speicherkosten finden Sie unter Informationen zur Abrechnung des Aurora-Datenspeichers.
-
In der können Sie diese Zahl in einem Diagramm sehen AWS Management Console, indem Sie die
MonitoringRegisterkarte auf der Detailseite für den Cluster aufrufen. -
Mit dem können Sie einen Befehl ausführen AWS CLI, der dem folgenden Linux-Beispiel ähnelt. Ersetzen Sie Ihre eigenen Werte durch die Start- und Endzeit und den Namen des Clusters.
aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \ --start-time "$(date -d '6 hours ago')" --end-time "$(date -d 'now')" --period 60 \ --namespace "AWS/RDS" \ --statistics Average Maximum Minimum \ --dimensions Name=DBClusterIdentifier,Value=my_cluster_identifierDie Ausgabe dieses Befehls sieht etwa so aus:
{ "Label": "VolumeBytesUsed", "Datapoints": [ { "Timestamp": "2020-08-04T21:25:00+00:00", "Average": 182871982080.0, "Minimum": 182871982080.0, "Maximum": 182871982080.0, "Unit": "Bytes" } ] }
Die folgenden Beispiele zeigen, wie Sie mithilfe von AWS CLI Befehlen auf einem Linux-System die Speichernutzung für einen Aurora-Cluster im Laufe der Zeit verfolgen können. Die Parameter --start-time und --end-time definieren das Gesamtzeitintervall als einen Tag. Der Parameter --period fordert die Messungen in einstündigen Intervallen an. Es ist sinnlos, einen kleinen --period-Wert zu wählen, da die Metriken in Intervallen und nicht kontinuierlich erfasst werden. Außerdem werden Aurora-Speichervorgänge manchmal für einige Zeit im Hintergrund fortgesetzt, nachdem die entsprechende SQL Anweisung abgeschlossen ist.
Das erste Beispiel gibt die Ausgabe im JSON Standardformat zurück. Die Datenpunkte werden in beliebiger Reihenfolge zurückgegeben, nicht nach Zeitstempel sortiert. Sie könnten diese JSON Daten in ein Diagrammtool importieren, um sie zu sortieren und zu visualisieren.
$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \
--start-time "$(date -d '1 day ago')" --end-time "$(date -d 'now')" --period 3600
--namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_cluster_id
{
"Label": "VolumeBytesUsed",
"Datapoints": [
{
"Timestamp": "2020-08-04T19:40:00+00:00",
"Maximum": 182872522752.0,
"Unit": "Bytes"
},
{
"Timestamp": "2020-08-05T00:40:00+00:00",
"Maximum": 198573719552.0,
"Unit": "Bytes"
},
{
"Timestamp": "2020-08-05T05:40:00+00:00",
"Maximum": 206827454464.0,
"Unit": "Bytes"
},
{
"Timestamp": "2020-08-04T17:40:00+00:00",
"Maximum": 182872522752.0,
"Unit": "Bytes"
},
... output omitted ...
In diesem Beispiel werden dieselben Daten zurückgegeben wie vorhin. Der Parameter --output stellt die Daten im kompakten Nur-Text-Format dar. Der Befehl aws cloudwatch übergibt seine Ausgabe an den Befehl sort. Der -k Parameter des sort Befehls sortiert die Ausgabe nach dem dritten Feld, dem Zeitstempel im Format Universal Coordinated Time (UTC).
$aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \ --start-time "$(date -d '1 day ago')" --end-time "$(date -d 'now')" --period 3600 \ --namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_cluster_id\ --output text | sort -k 3VolumeBytesUsed DATAPOINTS 182872522752.0 2020-08-04T17:41:00+00:00 Bytes DATAPOINTS 182872522752.0 2020-08-04T18:41:00+00:00 Bytes DATAPOINTS 182872522752.0 2020-08-04T19:41:00+00:00 Bytes DATAPOINTS 182872522752.0 2020-08-04T20:41:00+00:00 Bytes DATAPOINTS 187667791872.0 2020-08-04T21:41:00+00:00 Bytes DATAPOINTS 190981029888.0 2020-08-04T22:41:00+00:00 Bytes DATAPOINTS 195587244032.0 2020-08-04T23:41:00+00:00 Bytes DATAPOINTS 201048915968.0 2020-08-05T00:41:00+00:00 Bytes DATAPOINTS 205368492032.0 2020-08-05T01:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T02:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T03:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T04:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T05:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T06:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T07:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T08:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T09:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T10:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T11:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T12:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T13:41:00+00:00 Bytes DATAPOINTS 206827454464.0 2020-08-05T14:41:00+00:00 Bytes DATAPOINTS 206833664000.0 2020-08-05T15:41:00+00:00 Bytes DATAPOINTS 206833664000.0 2020-08-05T16:41:00+00:00 Bytes
Die sortierte Ausgabe zeigt an, wie viel Speicher zu Beginn und Ende des Überwachungszeitraums genutzt wurde. Sie können auch die Punkte in diesem Zeitraum finden, wenn Aurora mehr Speicher für den Cluster zugewiesen hat. Im folgenden Beispiel werden Linux-Befehle verwendet, um die VolumeBytesUsed-Start- und Endwerte als Gigabyte (GB) und als Gibibyte (GiB) neu zu formatieren. Gigabyte stehen für Einheiten, die in Potenzen von 10 gemessen werden und werden häufig in Diskussionen über Speicher für Rotationsfestplatten verwendet. Gibibytes stellen Einheiten dar, die in Zweierpotenzen gemessen werden. Aurora-Speichermessungen und -grenzwerte werden typischerweise in 2er-Potenzeinheiten wie Gibibyte und Tebibyte angegeben.
$GiB=$((1024*1024*1024))$GB=$((1000*1000*1000))$echo "Start: $((182872522752/$GiB)) GiB, End: $((206833664000/$GiB)) GiB"Start: 170 GiB, End: 192 GiB$echo "Start: $((182872522752/$GB)) GB, End: $((206833664000/$GB)) GB"Start: 182 GB, End: 206 GB
Die VolumeBytesUsed-Metrik gibt an,für wie viel Speicher im Cluster Gebühren anfallen. Daher ist es am besten, diesen Wert nach Möglichkeit zu minimieren. Diese Metrik enthält jedoch keinen Speicher, den Aurora intern im Cluster verwendet und nicht berechnet. Wenn sich Ihr Cluster dem Speicherlimit nähert und möglicherweise nicht genügend Speicherplatz zur Verfügung steht, ist es hilfreich, die AuroraVolumeBytesLeftTotal-Metrik zu überwachen und zu maximieren. Im folgenden Beispiel wird eine ähnliche Berechnung ausgeführt wie oben, jedoch für AuroraVolumeBytesLeftTotal statt VolumeBytesUsed.
$aws cloudwatch get-metric-statistics --metric-name "AuroraVolumeBytesLeftTotal" \ --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 3600 \ --namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_old_cluster_id\ --output text | sort -k 3AuroraVolumeBytesLeftTotal DATAPOINTS 140530528288768.0 2023-02-23T19:25:00+00:00 Count$TiB=$((1024*1024*1024*1024))$TB=$((1000*1000*1000*1000))$echo "$((69797067915264 / $TB)) TB remaining for this cluster"69 TB remaining for this cluster$echo "$((69797067915264 / $TiB)) TiB remaining for this cluster"63 TiB remaining for this cluster
Für einen Cluster, auf dem Aurora My SQL Version 2.09 oder höher oder Aurora Postgre ausgeführt wirdSQL, nimmt die von VolumeBytesUsed gemeldete freie Größe zu, wenn Daten hinzugefügt werden, und nimmt ab, wenn Daten entfernt werden. Im folgenden Beispiel wird gezeigt, wie dies geschieht. Dieser Bericht zeigt die maximale und minimale Speichergröße für einen Cluster in 15-Minuten-Intervallen an, wenn Tabellen mit temporären Daten erstellt und gelöscht werden. Der Bericht listet den Maximalwert vor dem Minimalwert auf. Um zu verstehen, wie sich die Speichernutzung innerhalb des 15-minütigen Intervalls verändert hat, interpretieren Sie daher die Zahlen von rechts nach links.
$aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \ --start-time "$(date -d '4 hours ago')" --end-time "$(date -d 'now')" --period 1800 \ --namespace "AWS/RDS" --statistics Maximum Minimum --dimensions Name=DBClusterIdentifier,Value=my_new_cluster_id--output text | sort -k 4VolumeBytesUsed DATAPOINTS 14545305600.0 14545305600.0 2020-08-05T20:49:00+00:00 Bytes DATAPOINTS 14545305600.0 14545305600.0 2020-08-05T21:19:00+00:00 Bytes DATAPOINTS 22022176768.0 14545305600.0 2020-08-05T21:49:00+00:00 Bytes DATAPOINTS 22022176768.0 22022176768.0 2020-08-05T22:19:00+00:00 Bytes DATAPOINTS 22022176768.0 22022176768.0 2020-08-05T22:49:00+00:00 Bytes DATAPOINTS 22022176768.0 15614263296.0 2020-08-05T23:19:00+00:00 Bytes DATAPOINTS 15614263296.0 15614263296.0 2020-08-05T23:49:00+00:00 Bytes DATAPOINTS 15614263296.0 15614263296.0 2020-08-06T00:19:00+00:00 Bytes
Das folgende Beispiel zeigt, dass bei einem Cluster, auf dem Aurora My SQL Version 2.09 oder höher oder Aurora Postgre ausgeführt wirdSQL, die von angegebene freie Größe die Größenbeschränkung von 128 TiB AuroraVolumeBytesLeftTotal widerspiegelt.
$aws cloudwatch get-metric-statistics --region us-east-1 --metric-name "AuroraVolumeBytesLeftTotal" \ --start-time "$(date -d '4 hours ago')" --end-time "$(date -d 'now')" --period 1800 \ --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBClusterIdentifier,Value=pq-57 \ --output text | sort -k 3AuroraVolumeBytesLeftTotal DATAPOINTS 140515818864640.0 2020-08-05T20:56:00+00:00 Count DATAPOINTS 140515818864640.0 2020-08-05T21:26:00+00:00 Count DATAPOINTS 140515818864640.0 2020-08-05T21:56:00+00:00 Count DATAPOINTS 140514866757632.0 2020-08-05T22:26:00+00:00 Count DATAPOINTS 140511020580864.0 2020-08-05T22:56:00+00:00 Count DATAPOINTS 140503168843776.0 2020-08-05T23:26:00+00:00 Count DATAPOINTS 140503168843776.0 2020-08-05T23:56:00+00:00 Count DATAPOINTS 140515818864640.0 2020-08-06T00:26:00+00:00 Count$TiB=$((1024*1024*1024*1024))$TB=$((1000*1000*1000*1000))$echo "$((140515818864640 / $TB)) TB remaining for this cluster"140 TB remaining for this cluster$echo "$((140515818864640 / $TiB)) TiB remaining for this cluster"127 TiB remaining for this cluster
Skalierung von Instances
Sie können Ihr Aurora-DB-Cluster skalieren, indem Sie die DB-Instance-Klasse für jede DB-Instance im DB-Cluster ändern. Aurora unterstützt mehrere DB-Instance-Klassen, die für Aurora optimiert sind, abhängig von der Kompatibilität des Datenbankmoduls.
| Datenbank-Engine | Skalierung von Instances |
|---|---|
|
Amazon Aurora Mein SQL |
|
|
Amazon Aurora Aurora-Postfach SQL |
Skalierung von Lesevorgängen
Sie können eine Skalierung von Lesevorgängen für Ihren Aurora-DB-Cluster erreichen, indem Sie bis zu 15 Replicas in Ihrem DB-Cluster erstellen. Jede Aurora-Replica gibt dieselben Daten aus dem Cluster-Volume mit minimaler Replica-Verzögerung zurück – im Normalfall weniger als 100 Millisekunden, nachdem die primäre Instance eine Aktualisierung geschrieben hat. Wenn sich Ihr Datenverkehr mit Lesevorgänge erhöht, können Sie zusätzliche Aurora-Replicas erstellen und sie direkt verbinden, um die Auslastung von Schreibvorgängen für Ihr DB-Cluster zu verteilen. Aurora-Replicas müssen sich nicht in derselben DB-Instance-Klasse wie die primäre Instance befinden.
Informationen zum Hinzufügen von Aurora-Replicas zu einem DB-Cluster finden Sie unter Hinzufügen von Aurora-Replicas zu einem DB-Cluster.
Verwalten von Verbindungen
Die maximale Anzahl der zulässigen Verbindungen mit einer Aurora-DB-Instance wird durch den Parameter max_connections in der Instance-Ebenen-Parametergruppe für die DB-Instance festgelegt. Der Standardwert dieses Parameters hängt von der DB-Instance-Klasse ab, die für die Kompatibilität von DB-Instance und Datenbank-Engine verwendet wird.
| Datenbank-Engine | Vorgabewert max_connections |
|---|---|
|
Amazon Aurora Mein SQL |
Siehe Maximale Anzahl an Verbindungen zu einer Aurora My SQL DB-Instance |
|
Amazon Aurora Aurora-Postfach SQL |
Siehe Maximale Anzahl an Verbindungen zu einer Aurora SQL Postgre-DB-Instance |
Tipp
Wenn Ihre Anwendungen häufig Verbindungen öffnen und schließen oder eine große Anzahl langlebiger Verbindungen offen halten, empfehlen wir Ihnen, Amazon RDS Proxy zu verwenden. RDSProxy ist ein vollständig verwalteter, hochverfügbarer Datenbank-Proxy, der mithilfe von Verbindungspooling Datenbankverbindungen sicher und effizient gemeinsam nutzt. Weitere Informationen zu RDS Proxy finden Sie unterAmazon RDS Proxy für Aurora verwenden.
Verwalten von Abfrageausführungsplänen
Wenn Sie die Abfrageplanverwaltung für Aurora Postgre verwendenSQL, haben Sie die Kontrolle darüber, welche Pläne der Optimierer ausführt. Weitere Informationen finden Sie unter Verwaltung von Abfrageausführungsplänen für Aurora Postgre SQL.
