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 Amazon Aurora MySQL
Skalierung von Aurora MySQL-DB-Instances
Sie können Aurora MySQL-DB-Instances auf zwei Arten skalieren, durch Skalierung der Instance oder durch Skalierung der Lesevorgänge. Weitere Informationen zur Lese-Skalierung finden Sie unter Skalierung von Lesevorgängen.
Sie können Ihr Aurora-MySQL-DB-Cluster skalieren, indem Sie die DB-Instance-Klasse für jede DB-Instance im DB-Cluster ändern. Aurora MySQL unterstützt mehrere DB-Instance-Klassen, die für Aurora optimiert sind. Verwenden Sie keine db.t2- oder db.t3-Instance-Klassen für größere Aurora-Cluster mit einer Größe von mehr als 40 TB. Die Spezifikationen der von Aurora MySQL unterstützten DB-Instance-Klassen finden Sie unter DB-Instance-Klassen von Amazon Aurora.
Anmerkung
Wir empfehlen, die T-DB-Instance-Klassen nur für Entwicklungs- und Testserver oder andere Nicht-Produktionsserver zu verwenden. Weitere Einzelheiten zu den T-Instance-Klassen finden Sie unter Verwendung von T-Instance-Klassen für Entwicklung und Tests.
Maximale Verbindungen zu einer Aurora MySQL-DB-Instance
Die maximale Anzahl der zulässigen Verbindungen mit einer Aurora MySQL-DB-Instance wird durch den Parameter max_connections in der Instance-Ebenen-Parametergruppe für die DB-Instance festgelegt.
Die folgende Tabelle listet den Standardwert von max_connections für jede DB-Instance auf, die für Aurora MySQL verfügbar ist. Sie können die maximal zulässige Anzahl von Verbindungen mit Ihrer Aurora MySQL-DB-Instance erhöhen, indem Sie die Instance auf eine DB-Instance-Klasse mit mehr Arbeitsspeicher skalieren oder einen größeren Wert für den Parameter max_connections in der DB-Parametergruppe für Ihre Instance festlegen, wobei ein Wert von bis zu 16 000 möglich ist.
Tipp
Wenn Ihre Anwendungen häufig Verbindungen öffnen und schließen oder langlebige Verbindungen in großer Zahl offen lassen, empfehlen wir Ihnen, Amazon-RDS-Proxy zu verwenden. RDS-Proxy ist ein vollständig verwalteter, hochverfügbarer Datenbank-Proxy, der Datenbankverbindungen sicher und effizient per Verbindungspooling freigibt. Weitere Informationen zu RDS-Proxy finden Sie unter Amazon-RDS-Proxy für Aurora.
Weitere Informationen dazu, wie Aurora Serverless v2-Instances diesen Parameter behandeln, finden Sie unter Maximale Anzahl der Verbindungen für Aurora Serverless v2.
| Instance class | Vorgabewert max_connections |
|---|---|
|
db.t2.small |
45 |
|
db.t2.Medium |
90 |
|
db.t3.small |
45 |
|
db.t3.medium |
90 |
|
db.t3.large |
135 |
|
db.t4g.medium |
90 |
|
db.t4g.large |
135 |
|
db.r3.large |
1000 |
|
db.r3.xlarge |
2000 |
|
db.r3.2xlarge |
3000 |
|
db.r3.4xlarge |
4000 |
|
db.r3.8xlarge |
5000 |
|
db.r4.large |
1000 |
|
db.r4.xlarge |
2000 |
|
db.r4.2xlarge |
3000 |
|
db.r4.4xlarge |
4000 |
|
db.r4.8xlarge |
5000 |
|
db.r4.16xlarge |
6 000 |
|
db.r5.large |
1000 |
|
db.r5.xlarge |
2000 |
|
db.r5.2xlarge |
3 000 |
|
db.r5.4xlarge |
4000 |
|
db.r5.8xlarge |
5000 |
|
db.r5.12xlarge |
6 000 |
|
db.r5.16xlarge |
6 000 |
|
db.r5.24xlarge |
7000 |
| db.r6g.large | 1000 |
| db.r6g.xlarge | 2000 |
| db.r6g.2xlarge | 3 000 |
| db.r6g.4xlarge | 4000 |
| db.r6g.8xlarge | 5000 |
| db.r6g.12xlarge | 6 000 |
| db.r6g.16xlarge | 6 000 |
| db.r6i.large | 1000 |
| db.r6i.xlarge | 2000 |
| db.r6i.2xlarge | 3 000 |
| db.r6i.4xlarge | 4000 |
| db.r6i.8xlarge | 5000 |
| db.r6i.12xlarge | 6 000 |
| db.r6i.16xlarge | 6 000 |
| db.r6i.24xlarge | 7000 |
| db.r6i.32xlarge | 7000 |
| db.r7g.large | 1000 |
| db.r7g.xlarge | 2000 |
| db.r7g.2xlarge | 3 000 |
| db.r7g.4xlarge | 4000 |
| db.r7g.8xlarge | 5000 |
| db.r7g.12xlarge | 6 000 |
| db.r7g.16xlarge | 6 000 |
| db.r7i.large | 1000 |
| db.r7i.xlarge | 2000 |
| db.r7i.2xlarge | 3 000 |
| db.r7i.4xlarge | 4000 |
| db.r7i.8xlarge | 5000 |
| db.r7i.12xlarge | 6 000 |
| db.r7i.16xlarge | 6 000 |
| db.r7i.24xlarge | 7000 |
| db.r7i.48xlarge | 8000 |
| db.r8g.large | 1000 |
| db.r8g.xlarge | 2000 |
| db.r8g.2xlarge | 3 000 |
| db.r8g.4xlarge | 4000 |
| db.r8g.8xlarge | 5000 |
| db.r8g.12xlarge | 6 000 |
| db.r8g.16xlarge | 6 000 |
| db.r8g.24xlarge | 7000 |
| db.r8g.48xlarge | 8000 |
| db.x2g.large | 2000 |
| db.x2g.xlarge | 3 000 |
| db.x2g.2xlarge | 4000 |
| db.x2g.4xlarge | 5000 |
| db.x2g.8xlarge | 6 000 |
| db.x2g.12xlarge | 7000 |
| db.x2g.16xlarge | 7000 |
Tipp
Die max_connections-Parameterberechnung verwendet die Protokollbasis 2 (unterschiedlich zum natürlichen Logarithmus) und den DBInstanceClassMemory-Wert in Byte für die ausgewählte Instance-Klasse von Aurora MySQL. Der Parameter akzeptiert nur Ganzzahlwerte, wobei Dezimalstellen bei Berechnungen gekürzt werden. Die Formel implementiert Verbindungslimits wie folgt:
Inkrement von 1 000 Verbindungen für größere R3-, R4- und R5-Instances
Inkrement von 45 Verbindungen für T2- und T3-Instance-Speichervarianten
Beispiel: Für db.r6g.large berechnet die Formel zwar 1 069,2, das System implementiert aber 1 000, um konsistente inkrementelle Muster aufrechtzuerhalten.
Wenn Sie eine neue Parametergruppe erstellen, um einen eigenen Standardwert für den Verbindungsgrenzwert zu erstellen, werden Sie feststellen, dass der Standard-Verbindungsgrenzwert mithilfe einer auf dem Wert DBInstanceClassMemory basierenden Formel abgeleitet wird. Wie in der vorhergehenden Tabelle dargestellt, erzeugt die Formel Verbindungsbegrenzungen, die bei einer Verdoppelung des Speichers über die progressiv größeren R3-, R4- und R5-Instances um jeweils 1000 und bei unterschiedlichen Speichergrößen von T2- und T3-Instances um 45 erhöht werden.
Weitere Informationen darüber, wie DBInstanceClassMemory berechnet wird, finden Sie unter Festlegen von DB-Parametern.
Aurora MySQL- und RDS für MySQL-DB-Instances weisen unterschiedliche Speicher-Overhead-Mengen auf. Daher kann der max_connections-Wert für Aurora MySQL- und RDS für MySQL-DB-Instances, die dieselbe Instance-Klasse verwenden, unterschiedlich sein. Die Werte in der Tabelle gelten nur für Aurora MySQL-DB-Instances.
Anmerkung
Die deutlich niedrigeren Verbindungsgrenzwerte für T2- und T3-Instances basieren darauf, dass diese Instances-Klassen bei Aurora nur für Entwicklungs- und Testszenarien und nicht für Produktionsworkloads vorgesehen sind.
Für Systeme, die Standardwerte für andere größere Arbeitsspeicherverbraucher verwenden, beispielsweise Pufferpool und Abfragezwischenspeicher, werden die Standard-Verbindungsgrenzwerte angepasst. Wenn Sie diese anderen Einstellungen für Ihr Cluster ändern, sollten Sie auch den Verbindungsgrenzwert ändern, um die Zu- oder Abnahme des verfügbaren Arbeitsspeichers in den DB-Instances zu berücksichtigen.
Temporäre Speicherlimits für Aurora MySQL
Aurora MySQL speichert Tabellen und Indizes im Aurora Speichersubsystem. Aurora MySQL verwendet separaten temporären oder lokalen Speicher für nicht persistente temporäre Dateien und temporäre Nicht-InnoDB-Tabellen. Zum lokalen Speicher gehören auch Dateien, die für Zwecke wie das Sortieren großer Datensätze während der Abfrageverarbeitung oder für Indexerstellungsvorgänge verwendet werden. Er umfasst keine temporären InnoDB-Tabellen.
Weitere Informationen zu temporären Tabellen in Aurora MySQL Version 3 finden Sie unter Neues temporäres Tabellenverhalten in Aurora-MySQL-Version 3. Weitere Informationen zu temporären Tabellen in Version 2 finden Sie unter Temporäres Tabellenverhalten in Aurora-MySQL-Version 2.
Die Daten und temporären Dateien auf diesen Volumes gehen beim Starten und Stoppen der DB-Instance sowie beim Austausch des Hosts verloren.
Diese lokalen Speicher-Volumes werden von Amazon Elastic Block Store (EBS) gestützt und können durch Einsatz einer größeren DB-Instance-Klasse erweitert werden. Weitere Informationen über Speicher finden Sie unter Amazon-Aurora-Speicher.
Lokaler Speicher wird auch für den Import von Daten aus Amazon S3 mit LOAD DATA FROM
S3 oder LOAD XML FROM S3 und für den Export von Daten zu S3 mit SELECT INTO OUTFILE S3 verwendet. Weitere Informationen zum Import aus und Export zu S3 finden Sie nachfolgend:
Aurora MySQL verwendet separaten permanenten Speicher für Fehlerprotokolle, allgemeine Protokolle, langsame Abfrageprotokolle und Prüfprotokolle für die meisten DB-Instance-Klassen von Aurora MySQL (ausgenommen Instance-Klassentypen mit Spitzenlastleistung wie db.t2, db.t3 und db.t4g). Die Daten auf diesem Volume werden beim Starten und Stoppen der DB-Instance sowie beim Austausch des Hosts beibehalten.
Dieses permanente Speicher-Volume wird ebenfalls von Amazon EBS unterstützt und hat eine feste Größe entsprechend der DB-Instance-Klasse. Eine Erweiterung durch die Verwendung einer größeren DB-Instance-Klasse ist nicht möglich.
Die folgende Tabelle zeigt die maximale Menge an temporärem und permanentem Speicher, die für jede DB-Instance-Klasse von Aurora MySQL verfügbar ist. Informationen zur Unterstützung der DB-Instance-Klasse für Aurora finden Sie unter DB-Instance-Klassen von Amazon Aurora.
| DB-Instance-Klasse (DB instance class) | Maximal verfügbarer temporärer/lokaler Speicher (GiB) | Zusätzlicher maximal verfügbarer Speicher für Protokolldateien (GiB) |
|---|---|---|
| db.x2g.16xlarge | 1280 | 500 |
| db.x2g.12xlarge | 960 | 500 |
| db.x2g.8xlarge | 640 | 500 |
| db.x2g.4xlarge | 320 | 500 |
| db.x2g.2xlarge | 160 | 60 |
| db.x2g.xlarge | 80 | 60 |
| db.x2g.large | 40 | 60 |
| db.r8g.48xlarge | 3840 | 500 |
| db.r8g.24xlarge | 1920 | 500 |
| db.r8g.16xlarge | 1280 | 500 |
| db.r8g.12xlarge | 960 | 500 |
| db.r8g.8xlarge | 640 | 500 |
| db.r8g.4xlarge | 320 | 500 |
| db.r8g.2xlarge | 160 | 60 |
| db.r8g.xlarge | 80 | 60 |
| db.r8g.large | 32 | 60 |
| db.r7i.48xlarge | 3840 | 500 |
| db.r7i.24xlarge | 1920 | 500 |
| db.r7i.16xlarge | 1280 | 500 |
| db.r7i.12xlarge | 960 | 500 |
| db.r7i.8xlarge | 640 | 500 |
| db.r7i.4xlarge | 320 | 500 |
| db.r7i.2xlarge | 160 | 60 |
| db.r7i.xlarge | 80 | 60 |
| db.r7i.large | 32 | 60 |
| db.r7g.16xlarge | 1280 | 500 |
| db.r7g.12xlarge | 960 | 500 |
| db.r7g.8xlarge | 640 | 500 |
| db.r7g.4xlarge | 320 | 500 |
| db.r7g.2xlarge | 160 | 60 |
| db.r7g.xlarge | 80 | 60 |
| db.r7g.large | 32 | 60 |
| db.r6i.32xlarge | 2560 | 500 |
| db.r6i.24xlarge | 1920 | 500 |
| db.r6i.16xlarge | 1280 | 500 |
| db.r6i.12xlarge | 960 | 500 |
| db.r6i.8xlarge | 640 | 500 |
| db.r6i.4xlarge | 320 | 500 |
| db.r6i.2xlarge | 160 | 60 |
| db.r6i.xlarge | 80 | 60 |
| db.r6i.large | 32 | 60 |
| db.r6g.16xlarge | 1280 | 500 |
| db.r6g.12xlarge | 960 | 500 |
| db.r6g.8xlarge | 640 | 500 |
| db.r6g.4xlarge | 320 | 500 |
| db.r6g.2xlarge | 160 | 60 |
| db.r6g.xlarge | 80 | 60 |
| db.r6g.large | 32 | 60 |
| db.r5.24xlarge | 1920 | 500 |
| db.r5.16xlarge | 1280 | 500 |
| db.r5.12xlarge | 960 | 500 |
| db.r5.8xlarge | 640 | 500 |
| db.r5.4xlarge | 320 | 500 |
| db.r5.2xlarge | 160 | 60 |
| db.r5.xlarge | 80 | 60 |
| db.r5.large | 32 | 60 |
| db.r4.16xlarge | 1280 | 500 |
| db.r4.8xlarge | 640 | 500 |
| db.r4.4xlarge | 320 | 500 |
| db.r4.2xlarge | 160 | 60 |
| db.r4.xlarge | 80 | 60 |
| db.r4.large | 32 | 60 |
| db.t4g.large | 32 | – |
| db.t4g.medium | 32 | – |
| db.t3.large | 32 | – |
| db.t3.medium | 32 | – |
| db.t3.small | 32 | – |
| db.t2.medium | 32 | – |
| db.t2.small | 32 | – |
Wichtig
Diese Werte stellen die theoretische maximale Menge an freiem Speicher auf jeder DB-Instance dar. Der tatsächliche lokale Speicher, der Ihnen zur Verfügung steht, ist möglicherweise niedriger. Aurora verwendet einen lokalen Speicher für seine Verwaltungsprozesse und die DB-Instance verwendet einen lokalen Speicher, noch bevor Sie Daten laden. Sie können den für eine bestimmte DB-Instance verfügbaren temporären Speicher mit der FreeLocalStorageCloudWatch-Metrik überwachen, die unter CloudWatch Amazon-Metriken für Amazon Aurora beschrieben wird. Sie können die Menge des freien Speichers zur Zeit überprüfen. Sie können auch die Menge des freien Speichers im Laufe der Zeit abzeichnen. Die Überwachung des freien Speichers im Laufe der Zeit hilft Ihnen festzustellen, ob der Wert steigt oder sinkt, oder um die Mindest-, Maximal- oder Durchschnittswerte zu ermitteln.
(Dies gilt nicht für Aurora Serverless v2.)
