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 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 Verwenden von 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.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 |
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 Speicher für nicht persistente temporäre Dateien. Aurora MySQL verwendet lokalen Speicher zum Speichern von Fehlerprotokollen, allgemeinen Protokollen, langsamen Abfrageprotokollen, Prüfungsprotokollen und temporären Tabellen, die nicht von InnoDB stammen. 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 finden Sie im Artikel Was ist im Aurora-MySQL-kompatiblen lokalen Speicher gespeichert und wie kann ich lokale Speicherprobleme beheben?
Diese lokalen Speicher-Volumes 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-Speicher und -Zuverlässigkeit.
Anmerkung
Beim Skalieren von DB-Instances, z. B. von db.r5.2xlarge auf db.r5.4xlarge, treten unter Umständen storage-optimization-Ereignisse auf.
Die folgende Tabelle zeigt die maximale Menge an temporärem 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 Aurora DB-Instance-Klassen.
| DB-Instance-Klasse | Maximal verfügbarer temporärer Speicher (GiB) |
|---|---|
| db.x2g.16xlarge | 1280 |
| db.x2g.12xlarge | 960 |
| db.x2g.8xlarge | 640 |
| db.x2g.4xlarge | 320 |
| db.x2g.2xlarge | 160 |
| db.x2g.xlarge | 80 |
| db.x2g.large | 40 |
| db.r6i.32xlarge | 2560 |
| db.r6i.24xlarge | 1920 |
| db.r6i.16xlarge | 1280 |
| db.r6i.12xlarge | 960 |
| db.r6i.8xlarge | 640 |
| db.r6i.4xlarge | 320 |
| db.r6i.2xlarge | 160 |
| db.r6i.xlarge | 80 |
| db.r6i.large | 32 |
| db.r6g.16xlarge | 1280 |
| db.r6g.12xlarge | 960 |
| db.r6g.8xlarge | 640 |
| db.r6g.4xlarge | 320 |
| db.r6g.2xlarge | 160 |
| db.r6g.xlarge | 80 |
| db.r6g.large | 32 |
| db.r5.24xlarge | 1920 |
| db.r5.16xlarge | 1280 |
| db.r5.12xlarge | 960 |
| db.r5.8xlarge | 640 |
| db.r5.4xlarge | 320 |
| db.r5.2xlarge | 160 |
| db.r5.xlarge | 80 |
| db.r5.large | 32 |
| db.r4.16xlarge | 1280 |
| db.r4.8xlarge | 640 |
| db.r4.4xlarge | 320 |
| db.r4.2xlarge | 160 |
| db.r4.xlarge | 80 |
| db.r4.large | 32 |
| 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 Metrik überwachen, die unter beschrieben wird 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.)
