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 Amazon Aurora Aurora-DB-Instance-Klassen.
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 | 3000 |
| 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 | 3000 |
| 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.2 x groß | 3000 |
| db.r7i.4x groß | 4000 |
| db.r7i.8xgroß | 5000 |
| db.r7i.12xlarge | 6 000 |
| db.r7i.16xlarge | 6 000 |
| db.r7i.24x groß | 7000 |
| db.r7i.48x groß | 8000 |
| db.r8g.groß | 1000 |
| db.r8g.xlarge | 2000 |
| db.r8g.2xlarge | 3000 |
| db.r8g.4xgroß | 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 | 3000 |
| 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 Logbasis 2 (anders als natürlicher Logarithmus) und den DBInstanceClassMemory Wert in Byte für die ausgewählte Aurora MySQL-Instance-Klasse. Der Parameter akzeptiert nur Ganzzahlwerte, wobei Dezimalstellen bei Berechnungen gekürzt werden. Die Formel implementiert Verbindungslimits wie folgt:
Verbindungsinkrement um 1000 für größere R3-, R4- und R5-Instanzen
Verbindungsinkrement um 45 für T2- und T3-Instance-Speichervarianten
Beispiel: Für db.r6g.large berechnet die Formel zwar 1069,2, das System implementiert aber 1000, 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 for MySQL-DB-Instances weisen unterschiedliche Speicher-Overhead-Mengen auf. Daher kann der max_connections-Wert für Aurora MySQL- und RDS for 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. Es enthält 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 Tablespace-Verhalten in Aurora My SQL Version 2.
Die Daten und temporären Dateien auf diesen Volumes gehen verloren, wenn die DB-Instance gestartet und gestoppt wird und wenn der Host ausgetauscht wird.
Diese lokalen Speichervolumes werden von Amazon Elastic Block Store (EBS) unterstützt und können durch die Verwendung einer größeren DB-Instance-Klasse erweitert werden. Weitere Informationen über Speicher finden Sie unter Amazon Aurora 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 nach S3 mit SELECT INTO OUTFILE S3 verwendet. Weitere Informationen zum Importieren von und Exportieren nach S3 finden Sie im Folgenden:
Aurora MySQL verwendet separaten permanenten Speicher für Fehlerprotokolle, allgemeine Protokolle, langsame Query-Logs und Audit-Logs für die meisten Aurora MySQL-DB-Instance-Klassen (ausgenommen Instance-Klassentypen mit hoher Leistung wie db.t2, db.t3 und db.t4g). Die Daten auf diesem Volume werden beim Starten und Stoppen der DB-Instance sowie beim Host-Austausch beibehalten.
Dieses permanente Speichervolumen wird ebenfalls von Amazon EBS unterstützt und hat eine feste Größe entsprechend der DB-Instance-Klasse. Es kann nicht durch die Verwendung einer größeren DB-Instance-Klasse erweitert werden.
Die folgende Tabelle zeigt die maximale Menge an temporärem und permanentem Speicher, die für jede Aurora MySQL-DB-Instance-Klasse verfügbar ist. Informationen zur Unterstützung der DB-Instance-Klasse für Aurora finden Sie unter Amazon Aurora Aurora-DB-Instance-Klassen.
| DB-Instance-Klasse | Maximal verfügbarer temporary/local Speicherplatz (GiB) | Zusätzlicher maximaler verfügbarer Speicherplatz 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.4xgroß | 320 | 500 |
| db.r8g.2xgroß | 160 | 60 |
| db.r8g.xlarge | 80 | 60 |
| db.r8g.groß | 32 | 60 |
| db.r7i.48x groß | 3840 | 500 |
| db.r7i.24x groß | 1920 | 500 |
| db.r7i.16xlarge | 1280 | 500 |
| db.r7i.12xlarge | 960 | 500 |
| db.r7i.8 x groß | 640 | 500 |
| db.r7i.4x groß | 320 | 500 |
| db.r7i.2xgroß | 160 | 60 |
| db.r7i.xlarge | 80 | 60 |
| db.r7i.groß | 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 FreeLocalStorage CloudWatch unter beschriebenen Metrik überwachen. CloudWatch Amazon-Metriken für Amazon Aurora 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.)
