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.
# Aurora mit MySQL Version 3 ist kompatibel mit MySQL 8.0
Sie können Aurora MySQL Version 3 verwenden, um die neuesten MySQL-kompatiblen Funktionen, Leistungsverbesserungen und Bugfixes zu erhalten. Im Folgenden erfahren Sie mehr über Aurora MySQL Version 3 mit MySQL 8.0 Kompatibilität. Sie können lernen, wie Sie Ihre Cluster und Anwendungen auf Aurora MySQL Version 3 aktualisieren.
Einige Aurora-Funktionen wie Aurora Serverless v2 erfordern Aurora MySQL Version 3.
**Topics**
+ [Funktionen aus der Community Edition von MySQL 8.0](#AuroraMySQL.8.0-features-community)
+ [Aurora MySQL Version 3 als Voraussetzung für Aurora MySQL Serverless v2](#AuroraMySQL.serverless-v2-8.0-prereq)
+ [Versionshinweise für Aurora MySQL Version 3](#AuroraMySQL.mysql80-bugs-fixed)
+ [Neue -Optimierungen für parallele Abfragen](#AuroraMySQL.8.0-features-pq)
+ [Optimierungen reduzieren die Neustartzeit der Datenbank](#ReducedRestartTime)
+ [Neues temporäres Tabellenverhalten in Aurora-MySQL-Version 3](ams3-temptable-behavior.md)
+ [Vergleich von Aurora-MySQL-Version 2 und Aurora-MySQL-Version 3](AuroraMySQL.Compare-v2-v3.md)
+ [Vergleich von Aurora-MySQL-Version 3 und MySQL 8.0 Community Edition](AuroraMySQL.Compare-80-v3.md)
+ [Upgrade auf Aurora MySQL Version 3](AuroraMySQL.mysql80-upgrade-procedure.md)
## Funktionen aus der Community Edition von MySQL 8.0
Die erste Version von Aurora MySQL Version 3 ist mit der Community Edition von MySQL 8.0.23 kompatibel. MySQL 8.0 führt mehrere neue Funktionen ein, darunter die folgenden:
+ Unterstützung der Atomic Data Definition Language (DDL) Weitere Informationen finden Sie unter [Unterstützung der Atomic Data Definition Language (DDL)](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.Compare-v2-v3-atomic-ddl).
+ JSON-Funktionen Weitere Informationen zur Nutzung finden Sie unter[JSON-Funktionen](https://dev.mysql.com/doc/refman/8.0/en/json-functions.html)im*MySQL-Referenzhandbuch*aus.
+ Fensterfunktionen. Weitere Informationen zur Nutzung finden Sie unter[Fensterfunktionen](https://dev.mysql.com/doc/refman/8.0/en/window-functions.html)im*MySQL-Referenzhandbuch*aus.
+ Gemeinsame Tabellenausdrücke (CTEs) unter Verwendung der`WITH`-Klausel. Weitere Informationen zur Nutzung finden Sie unter[WITH (Allgemeine Tabellenausdrücke)](https://dev.mysql.com/doc/refman/8.0/en/with.html)im*MySQL-Referenzhandbuch*aus.
+ Optimiert`ADD COLUMN`und`RENAME COLUMN`-Klauseln für`ALTER TABLE`statement. Diese Optimierungen werden „Instant DDL“ genannt. Aurora MySQL Version 3 ist mit der MySQL-Instant-DDL-Funktion der Community kompatibel. Die ehemalige Aurora Fast DDL-Funktion wird nicht verwendet. Informationen zur Verwendung für Instant DDL finden Sie unter[Sofortige DDL (Aurora MySQL Version 3)](AuroraMySQL.Managing.FastDDL.md#AuroraMySQL.mysql80-instant-ddl)aus.
+ Absteigende, funktionale und unsichtbare Indizes. Weitere Informationen zur Nutzung finden Sie unter[Unsichtbare Indizes](https://dev.mysql.com/doc/refman/8.0/en/invisible-indexes.html),[Absteigende Indizes](https://dev.mysql.com/doc/refman/8.0/en/descending-indexes.html), und[CREATE INDEX-Anweisung](https://dev.mysql.com/doc/refman/8.0/en/create-index.html#create-index-functional-key-parts)im*MySQL-Referenzhandbuch*aus.
+ Rollenbasierte Berechtigungen, die durch SQL-Anweisungen gesteuert werden. Weitere Informationen zu Änderungen am Berechtigungsmodell finden Sie unter[Rollenbasiertes Berechtigungsmodell](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model)aus.
+ `NOWAIT`und`SKIP LOCKED`-Klauseln mit`SELECT ... FOR SHARE`statement. Diese Klauseln vermeiden es, darauf zu warten, dass andere Transaktionen Zeilensperren freigeben. Weitere Informationen zu[ Lesesperren](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html) finden Sie im* MySQL-Referenzhandbuch*.
+ Verbesserungen der Binärprotokollreplikation (binlog). Die Aurora MySQL-Details finden Sie unter[Binäre Protokoll-Replikation](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.mysql80-binlog)aus. Insbesondere können Sie eine gefilterte Replikation durchführen. Informationen zur Verwendung zur gefilterten Replikation finden Sie unter[So bewerten Server Replikationsfilterregeln](https://dev.mysql.com/doc/refman/8.0/en/replication-rules.html)im*MySQL-Referenzhandbuch*aus.
+ Hinweise Einige der MySQL 8.0-kompatiblen Hinweise wurden bereits auf Aurora MySQL Version 2 zurückportiert. Weitere Informationen zur Sicherheit im Zusammenhang mit Aurora MySQL finden Sie unter [Aurora-MySQL-Hinweise](AuroraMySQL.Reference.Hints.md). Eine vollständige Liste der Hinweise in MySQL 8.0 finden Sie unter[Optimierungshinweise](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html)im*MySQL-Referenzhandbuch*aus.
Die vollständige Liste der Funktionen, die zur MySQL 8.0 Community Edition hinzugefügt wurden, finden Sie im Blogbeitrag[Die vollständige Liste der neuen Funktionen in MySQL 8.0](https://dev.mysql.com/blog-archive/the-complete-list-of-new-features-in-mysql-8-0/)aus.
Aurora MySQL Version 3 enthält auch Änderungen an Schlüsselwörtern für inklusive Sprache, die von der Community MySQL 8.0.26 zurückportiert wurden. Einzelheiten zu diesen Änderungen finden Sie unter[Inklusive Sprachänderungen für Aurora MySQL Version 3](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language)aus.
## Aurora MySQL Version 3 als Voraussetzung für Aurora MySQL Serverless v2
Aurora MySQL Version 3 ist Voraussetzung für alle DB-Instances in einem Aurora-MySQL-Serverless-v2-Cluster. Aurora MySQL Serverless v2 enthält Unterstützung für Reader-Instances in einem DB-Cluster und andere Aurora-Funktionen, die für Aurora MySQL Serverless v1 nicht verfügbar sind. Diese Version bietet auch eine schnellere und stärker granulare Skalierung als Aurora MySQL Serverless v1.
## Versionshinweise für Aurora MySQL Version 3
Die Versionshinweise für alle Versionen von Aurora MySQL Version 3 finden Sie unter [Aktualisierungen der Datenbank-Engine für Amazon Aurora MySQL Version 3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html) in den *Versionshinweisen für Aurora MySQL*.
## Neue -Optimierungen für parallele Abfragen
Die parallele Aurora-Abfrageoptimierung gilt nun für mehr SQL-Operationen:
+ Die parallele Abfrage gilt jetzt für Tabellen, die die Datentypen enthalten`TEXT`,`BLOB`,`JSON`,`GEOMETRY`, und`VARCHAR`und`CHAR`länger als 768 Bytes.
+ Parallele Abfragen können Abfragen mit partitionierten Tabellen optimieren.
+ Eine parallele Abfrage kann Abfragen mit Aggregatfunktionsaufrufen in der Auswahlliste und der`HAVING`-Klausel.
Weitere Informationen zu Enhanced Monitoring finden Sie unter [Upgrade paralleler Abfrage-Cluster auf Aurora-MySQL-Version 3](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2). Allgemeine Informationen zu Aurora-Sicherungen finden Sie unter [Parallel Query für Amazon Aurora MySQL](aurora-mysql-parallel-query.md).
## Optimierungen reduzieren die Neustartzeit der Datenbank
Ihr Aurora-MySQL-DB-Cluster muss sowohl bei geplanten als auch bei ungeplanten Ausfällen hochverfügbar sein.
Datenbankadministratoren müssen gelegentlich Datenbankwartungen durchführen. Diese Wartungsmaßnahmen umfassen Datenbank-Patches, Upgrades, Änderungen von Datenbankparametern, die einen manuellen Neustart erfordern, die Durchführung eines Failovers, um den Zeitaufwand für Instance-Klassenänderungen zu reduzieren, usw. Solche geplanten Aktionen machen Ausfallzeiten erforderlich.
Ausfallzeiten können jedoch auch durch ungeplante Aktionen verursacht werden, beispielsweise durch einen unerwarteten Failover aufgrund eines zugrunde liegenden Hardwarefehlers oder durch die Drosselung von Datenbankressourcen. Alle diese geplanten und ungeplanten Aktionen führen zu einem Neustart der Datenbank.
In Aurora MySQL Version 3.05 und höher haben wir Optimierungen eingeführt, die die Neustartzeit der Datenbank reduzieren. Diese Optimierungen sorgen für bis zu 65 % weniger Ausfallzeiten als ohne Optimierungen und weniger Unterbrechungen Ihrer Datenbank-Workloads nach einem Neustart.
Während des Datenbankstarts werden viele interne Speicherkomponenten initialisiert. Die größte dieser Komponenten ist der [InnoDB-Pufferpool](https://aws.amazon.com/blogs/database/best-practices-for-amazon-aurora-mysql-database-configuration/), der in Aurora MySQL standardmäßig 75 % der Instance-Speichergröße ausmacht. Unsere Tests haben ergeben, dass die Initialisierungszeit proportional zur Größe des InnoDB-Pufferpools ist und daher mit der Größe der DB-Instance-Klasse skaliert. Während dieser Initialisierungsphase kann die Datenbank keine Verbindungen akzeptieren, wodurch es zu längeren Ausfallzeiten bei Neustarts kommt. In der ersten Phase des schnellen Neustarts von Aurora MySQL wird die Initialisierung des Pufferpools optimiert, wodurch die Zeit für die Datenbankinitialisierung und damit die Gesamtneustartzeit reduziert werden kann.
Weitere Informationen finden Sie im Blog [Reduce downtime with Amazon Aurora MySQL database restart time optimizations](https://aws.amazon.com/blogs/database/reduce-downtime-with-amazon-aurora-mysql-database-restart-time-optimizations/).
# Neues temporäres Tabellenverhalten in Aurora-MySQL-Version 3
Aurora MySQL Version 3 behandelt temporäre Tabellen anders als frühere Aurora-MySQL-Versionen. Dieses neue Verhalten wird von der Community Edition von MySQL 8.0 geerbt. Es gibt zwei Arten von temporären Tabellen, die mit Aurora MySQL Version 3 erstellt werden können:
+ Interne (oder *implizite*) temporäre Tabellen — Erstellt von der Aurora MySQL-Engine für Operationen wie Sortieraggregation, abgeleitete Tabellen oder allgemeine Tabellenausdrücke ()CTEs.
+ Vom Benutzer erstellte (oder *explizite*) temporäre Tabellen – werden von der Aurora-MySQL-Engine erstellt, wenn Sie die Anweisung `CREATE TEMPORARY TABLE` verwenden.
Es gibt zusätzliche Überlegungen sowohl für interne als auch für vom Benutzer erstellte temporäre Tabellen auf Aurora-Reader-DB-Instances. Diese werden in den folgenden Abschnitten erläutert.
**Topics**
+ [Speicher-Engine für interne (implizite) temporäre Tabellen](#ams3-temptable-behavior-engine)
+ [Begrenzung der Größe interner temporärer Tabellen im Arbeitsspeicher](#ams3-temptable-behavior-limit)
+ [Abschwächung von Füllungsgradproblemen bei internen temporären Tabellen auf Aurora Replicas](#ams3-temptable-behavior-mitigate)
+ [Optimieren des temptable\$1max\$1mmap-Parameters auf Aurora MySQL-DB-Instances](#ams-optimize-temptable_max_mmap)
+ [Vom Benutzer erstellte (explizite) temporäre Tabellen auf Reader-DB-Instances](#ams3-temptable-behavior.user)
+ [Fehler bei der Erstellung temporärer Tabellen und Abhilfemaßnahmen](#ams3-temptable-behavior.errors)
## Speicher-Engine für interne (implizite) temporäre Tabellen
Beim Generieren von Zwischenergebnismengen versucht Aurora MySQL zunächst, in temporäre Tabellen im Arbeitsspeicher zu schreiben. Dies ist aufgrund inkompatibler Datentypen oder konfigurierter Grenzwerte möglicherweise nicht erfolgreich. In diesem Fall wird die temporäre Tabelle in eine temporäre Tabelle auf dem Datenträger konvertiert, anstatt im Arbeitsspeicher abgelegt zu werden. Weitere Informationen hierzu finden Sie unter [Verwendung interner temporärer Tabellen in MySQL](https://dev.mysql.com/doc/refman/8.0/en/internal-temporary-tables.html) in der MySQL-Dokumentation.
In Aurora-MySQL-Version 3 unterscheidet sich die Funktionsweise interner temporärer Tabellen von früheren Aurora-MySQL-Versionen. Anstatt sich bei solchen temporären Tabellen zwischen den InnoDB- und MyISAM-Speicher-Engines zu entscheiden, wählen Sie jetzt zwischen den `TempTable`- und `MEMORY`-Speicher-Engines.
Mit der `TempTable`-Speicher-Engine können Sie eine zusätzliche Auswahl für den Umgang mit bestimmten Daten treffen. Die betroffenen Daten überlaufen den Speicherpool, der alle internen temporären Tabellen für die DB-Instance enthält.
Diese Optionen können die Leistung von Abfragen beeinflussen, die hohe Mengen an temporären Daten generieren, z. B. während der Durchführung von Aggregationen wie `GROUP BY` auf großen Tabellen.
**Tipp**
Wenn Ihre Workload Abfragen enthält, die interne temporäre Tabellen generieren, bestätigen Sie, wie Ihre Anwendung mit dieser Änderung funktioniert, indem Sie Benchmarks ausführen und leistungsbezogene Metriken überwachen.
In einigen Fällen passt die Menge an temporären Daten in`TempTable`Speicherpool oder überläuft den Speicherpool nur um einen kleinen Betrag. In diesen Fällen empfehlen wir die `TempTable`-Einstellung für interne temporäre Tabellen und speicherzugeordnete Dateien, um Überlaufdaten zu speichern. Dies ist die Standardeinstellung.
Die `TempTable`-Speicher-Engine ist die Standardeinstellung. `TempTable` verwendet einen gemeinsamen Speicherpool für alle temporären Tabellen, die diese Engine verwenden, anstelle eines maximalen Speicherlimits pro Tabelle. Die Größe dieses Speicherpools wird durch den Parameter [temptable\$1max\$1ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram) angegeben. Der Wert dieses Parameters beträgt standardmäßig 1 GiB bei DB-Instances mit 16 oder mehr GiB Arbeitsspeicher und 16 MB bei DB-Instances mit weniger als 16 GB Arbeitsspeicher. Die Größe des Speicherpools beeinflusst den Speicherverbrauch auf Sitzungsebene.
Bei Verwendung der Speicher-Engine `TempTable` kann es vorkommen, dass die temporären Daten die Größe des Speicherpools überschreiten. In diesem Fall speichert Aurora MySQL die Überlaufdaten mithilfe eines sekundären Mechanismus.
Sie können den Parameter [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) festlegen, um anzugeben, ob die Daten zu temporären Dateien im Arbeitsspeicher oder zu internen temporären Tabellen von InnoDB auf der Festplatte überlaufen werden. Die verschiedenen Datenformate und Überlaufkriterien dieser Überlaufmechanismen können sich auf die Abfrageleistung auswirken. Sie tun dies, indem sie die Menge der auf die Festplatte geschriebenen Daten und die Nachfrage nach Festplattenspeicherdurchsatz beeinflussen.
Version 3 von Aurora MySQL speichert die Überlaufdaten auf folgende Weise:
+ Bei der Writer-DB-Instance befinden sich die Dateien, die zu internen temporären Tabellen von InnoDB oder zu speicherzugeordneten Dateien überlaufen, im lokalen Speicher der Instance.
+ Bei Reader-DB-Instances befinden sich die Überlaufdaten immer in speicherzugeordneten temporären Dateien im lokalen Speicher.
Schreibgeschützte Instances können keine Daten auf dem Aurora-Cluster-Volume speichern.
Die Konfigurationsparameter für interne temporäre Tabellen gelten unterschiedlich für die Writer- und Reader-Instancees in Ihrem Cluster.
+ Für Reader-Instances verwendet Aurora MySQL immer die Speicher–Engine `TempTable`.
+ Die Größe für `temptable_max_mmap` beträgt für Writer- und Reader-Instances unabhängig von der Speichergröße der DB-Instance standardmäßig 1 GB. Sie können diesen Wert sowohl für Writer- als auch für Reader-Instances anpassen.
+ Die Einstellung von `temptable_max_mmap` auf `0` deaktiviert die Verwendung von temporären Dateien mit Speicherzuordnung auf Writer-Instances.
+ Sie können `0` auf Reader-Instances nicht auf `temptable_max_mmap` setzen.
**Anmerkung**
Es wird nicht empfohlen, den [temptable\$1use\$1mmap-Parameter](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_use_mmap) zu verwenden. Dieser ist veraltet, und es wird erwartet, dass die Unterstützung dafür in einer künftigen MySQL-Version entfernt wird.
## Begrenzung der Größe interner temporärer Tabellen im Arbeitsspeicher
Wie in [Speicher-Engine für interne (implizite) temporäre Tabellen](#ams3-temptable-behavior-engine) erwähnt, können Sie temporäre Tabellenressourcen global steuern, indem Sie die Einstellungen [temptable\$1max\$1ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram) und [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) verwenden.
Sie können die Größe jeder einzelnen internen temporären Tabelle im Arbeitsspeicher auch einschränken, indem Sie den DB-Parameter [tmp\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmp_table_size) verwendenParameter. Dieses Limit soll verhindern, dass einzelne Abfragen übermäßig viele globale temporäre Tabellenressourcen verbrauchen, was sich auf die Leistung gleichzeitiger Abfragen auswirken kann, die diese Ressourcen benötigen.
Der Parameter `tmp_table_size` definiert die maximale Größe temporärer Tabellen, die von der `MEMORY`-Speicher-Engine in Aurora-MySQL-Version 3 erstellt werden.
In Aurora-MySQL-Version 3.04 und höher definiert der Parameter `tmp_table_size` auch die maximale Größe temporärer Tabellen, die von der `TempTable`-Speicher-Engine erstellt werden, wenn der DB-Parameter `aurora_tmptable_enable_per_table_limit` auf `ON` festgelegt ist. Dieses Verhalten ist standardmäßig deaktiviert (`OFF`). Dies entspricht dem Verhalten von Aurora-MySQL-Version 3.03 und niedrigeren Versionen.
+ Wenn `aurora_tmptable_enable_per_table_limit` `OFF` ist ,wird `tmp_table_size` nicht für interne temporäre Tabellen im Arbeitsspeicher berücksichtigt, die von der`TempTable`-Speicher-Engine erstellt wurden.
Das globale `TempTable`-Ressourcenlimit gilt jedoch weiterhin. Aurora MySQL verhält sich wie folgt, wenn das globale `TempTable`-Ressourcenlimit erreicht wird:
+ Writer-DB-Instances – Aurora MySQL konvertiert die temporäre Tabelle im Arbeitsspeicher automatisch in eine temporäre InnoDB-Tabelle auf der Festplatte.
+ Reader-DB-Instances – Die Abfrage endet mit einem Fehler.
```
ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlxx_xxx' is full
```
+ Wenn `aurora_tmptable_enable_per_table_limit` `ON` ist, verhält sich Aurora MySQL wie folgt, wenn das `tmp_table_size`-Limit erreicht wird:
+ Writer-DB-Instances – Aurora MySQL konvertiert die temporäre Tabelle im Arbeitsspeicher automatisch in eine temporäre InnoDB-Tabelle auf der Festplatte.
+ Reader-DB-Instances – Die Abfrage endet mit einem Fehler.
```
ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlxx_xxx' is full
```
In diesem Fall gelten sowohl das globale `TempTable`-Ressourcenlimit als auch das Limit pro Tabelle.
**Anmerkung**
Der `aurora_tmptable_enable_per_table_limit`-Parameter hat keine Auswirkungen, wenn [interne\$1tmp\$1mem\$1storage\$1engine](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_internal_tmp_mem_storage_engine) auf `MEMORY` eingestellt ist. In diesem Fall wird die maximale Größe einer temporären Tabelle im Arbeitsspeicher durch den Wert [tmp\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmp_table_size) oder [max\$1heap\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_heap_table_size) definiert, je nachdem, welcher Wert kleiner ist.
Die folgenden Beispiele zeigen das Verhalten des `aurora_tmptable_enable_per_table_limit`-Parameters für Writer- und Reader-DB-Instances.
**Example einer Writer-DB-Instance mit der Einstellung `aurora_tmptable_enable_per_table_limit` auf `OFF`**
Die temporäre Tabelle im Arbeitsspeicher wird nicht in eine temporäre InnoDB-Tabelle auf dem Datenträger konvertiert.
```
mysql> set aurora_tmptable_enable_per_table_limit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap;
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| 0 | 3.04.0 | 0 | 1073741824 | 1073741824 |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
1 row in set (0.00 sec)
mysql> show status like '%created_tmp_disk%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 0 |
+-------------------------+-------+
1 row in set (0.00 sec)
mysql> set cte_max_recursion_depth=4294967295;
Query OK, 0 rows affected (0.00 sec)
mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 60000000) SELECT max(n) FROM cte;
+----------+
| max(n) |
+----------+
| 60000000 |
+----------+
1 row in set (13.99 sec)
mysql> show status like '%created_tmp_disk%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 0 |
+-------------------------+-------+
1 row in set (0.00 sec)
```
**Example einer Writer-DB-Instance mit der Einstellung `aurora_tmptable_enable_per_table_limit` auf `ON`**
Die temporäre Tabelle im Arbeitsspeicher wird in eine temporäre InnoDB-Tabelle auf dem Datenträger konvertiert.
```
mysql> set aurora_tmptable_enable_per_table_limit=1;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@tmp_table_size;
+--------------------+------------------+------------------------------------------+------------------+
| @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@tmp_table_size |
+--------------------+------------------+------------------------------------------+------------------+
| 0 | 3.04.0 | 1 | 16777216 |
+--------------------+------------------+------------------------------------------+------------------+
1 row in set (0.00 sec)
mysql> set cte_max_recursion_depth=4294967295;
Query OK, 0 rows affected (0.00 sec)
mysql> show status like '%created_tmp_disk%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 0 |
+-------------------------+-------+
1 row in set (0.00 sec)
mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 6000000) SELECT max(n) FROM cte;
+---------+
| max(n) |
+---------+
| 6000000 |
+---------+
1 row in set (4.10 sec)
mysql> show status like '%created_tmp_disk%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 1 |
+-------------------------+-------+
1 row in set (0.00 sec)
```
**Example einer Reader-DB-Instance mit der Einstellung `aurora_tmptable_enable_per_table_limit` auf `OFF`**
Die Abfrage wird ohne Fehler beendet, weil `tmp_table_size` nicht zutrifft, und das globale `TempTable`-Ressourcenlimit wurde nicht erreicht.
```
mysql> set aurora_tmptable_enable_per_table_limit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap;
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| 1 | 3.04.0 | 0 | 1073741824 | 1073741824 |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
1 row in set (0.00 sec)
mysql> set cte_max_recursion_depth=4294967295;
Query OK, 0 rows affected (0.00 sec)
mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 60000000) SELECT max(n) FROM cte;
+----------+
| max(n) |
+----------+
| 60000000 |
+----------+
1 row in set (14.05 sec)
```
**Example einer Reader-DB-Instance mit der Einstellung `aurora_tmptable_enable_per_table_limit` auf `OFF`**
Diese Abfrage erreicht das globale TempTable Ressourcenlimit, wenn sie auf OFF `aurora_tmptable_enable_per_table_limit` gesetzt ist. Die Abfrage endet mit einem Fehler auf den Reader-Instances.
```
mysql> set aurora_tmptable_enable_per_table_limit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap;
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| 1 | 3.04.0 | 0 | 1073741824 | 1073741824 |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
1 row in set (0.00 sec)
mysql> set cte_max_recursion_depth=4294967295;
Query OK, 0 rows affected (0.01 sec)
mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 120000000) SELECT max(n) FROM cte;
ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlfd_1586_2' is full
```
**Example einer Reader-DB-Instance mit der Einstellung `aurora_tmptable_enable_per_table_limit` auf `ON`**
Die Abfrage endet mit einem Fehler, wenn das `tmp_table_size`-Limit erreicht wird.
```
mysql> set aurora_tmptable_enable_per_table_limit=1;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@tmp_table_size;
+--------------------+------------------+------------------------------------------+------------------+
| @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@tmp_table_size |
+--------------------+------------------+------------------------------------------+------------------+
| 1 | 3.04.0 | 1 | 16777216 |
+--------------------+------------------+------------------------------------------+------------------+
1 row in set (0.00 sec)
mysql> set cte_max_recursion_depth=4294967295;
Query OK, 0 rows affected (0.00 sec)
mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 6000000) SELECT max(n) FROM cte;
ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlfd_8_2' is full
```
## Abschwächung von Füllungsgradproblemen bei internen temporären Tabellen auf Aurora Replicas
Sie können Probleme mit der Größenbeschränkung für temporäre Tabellen vermeiden, indem Sie die Parameter `temptable_max_ram` und `temptable_max_mmap` auf einen kombinierten Wert festlegen, der die Anforderungen Ihrer Workloads erfüllen kann.
Seien Sie vorsichtig, wenn Sie den Wert des Parameters `temptable_max_ram` festlegen. Wenn der Wert zu hoch eingestellt wird, wird der verfügbare Speicher auf der Datenbankinstanz reduziert, was zu Störungen führen out-of-memory kann. Überwachen Sie den durchschnittlichen möglichen freien Arbeitsspeicher der DB-Instance. Ermitteln Sie dann einen geeigneten Wert für `temptable_max_ram`, damit Sie immer noch angemessenen freien Speicherplatz auf der Instance zur Verfügung haben. Weitere Informationen finden Sie unter [Probleme mit freisetzbarem Speicher in Amazon Aurora](CHAP_Troubleshooting.md#Troubleshooting.FreeableMemory).
Es ist auch wichtig, die Größe des lokalen Speichers und die Speicherplatzbelegung durch die temporäre Tabelle zu überwachen. Sie können den für eine bestimmte DB-Instance verfügbaren temporären Speicher mit der `FreeLocalStorage` CloudWatch Amazon-Metrik überwachen, die unter beschrieben ist[CloudWatch Amazon-Metriken für Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md).
**Anmerkung**
Dieses Verfahren funktioniert nicht, wenn der `aurora_tmptable_enable_per_table_limit`-Parameter auf `ON` festgelegt ist. Weitere Informationen finden Sie unter [Begrenzung der Größe interner temporärer Tabellen im Arbeitsspeicher](#ams3-temptable-behavior-limit).
**Example 1**
Sie wissen, dass Ihre temporären Tabellen auf eine kumulative Größe von 20 GiB anwachsen. Sie möchten temporäre In-Memory-Tabellen auf 2 GiB festlegen und auf maximal 20 GiB auf der Festplatte anwachsen lassen.
Setzen Sie `temptable_max_ram` auf **2,147,483,648** und `temptable_max_mmap` auf **21,474,836,480**. Diese Werte werden in Byte angegeben.
Diese Parametereinstellungen stellen sicher, dass Ihre temporären Tabellen auf eine kumulative Summe von 22 GiB anwachsen können.
**Example 2**
Ihre aktuelle Instance-Größe ist 16xlarge oder größer. Sie kennen nicht die Gesamtgröße der temporären Tabellen, die Sie möglicherweise benötigen. Sie möchten bis zu 4 GiB im Arbeitsspeicher und den maximal verfügbaren Speicher auf der Festplatte nutzen können.
Setzen Sie `temptable_max_ram` auf **4,294,967,296** und `temptable_max_mmap` auf **1,099,511,627,776**. Diese Werte werden in Byte angegeben.
Hier legen Sie `temptable_max_mmap` auf 1 TiB fest, was weniger als der maximale lokale Speicher von 1,2 TiB auf einer Aurora-DB-Instance der Größe 16xlarge ist.
Passen Sie bei einer kleineren Instance-Größe den Wert `temptable_max_mmap` an, damit der verfügbare lokale Arbeitsspeicher nicht vollständig belegt wird. Bei einer 2xlarge-Instance stehen für den lokalen Speicher beispielsweise nur 160 GiB zur Verfügung. Daher empfehlen wir, den Wert auf weniger als 160 GiB einzustellen. Weitere Informationen über den verfügbaren lokalen Speicher für DB-Instance-Größen finden Sie unter [Temporäre Speicherlimits für Aurora MySQLTemporäre Speicherlimits](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage).
## Optimieren des temptable\$1max\$1mmap-Parameters auf Aurora MySQL-DB-Instances
Der `temptable_max_mmap`-Parameter in Aurora MySQL steuert die maximale Menge an lokalem Festplattenspeicher, die von speicherzugeordneten Dateien genutzt werden kann, bevor sie in die temporären InnoDB-Tabellen auf der Festplatte überlaufen (auf Writer-DB-Instances) oder einen Fehler verursachen (auf Reader-DB-Instances). Wenn Sie diesen DB-Instance-Parameter richtig einstellen, kann dies dazu beitragen, die Leistung Ihrer DB-Instances zu optimieren.
**Voraussetzungen**
1. Stellen Sie sicher, dass das Leistungsschema aktiviert ist. Sie können dies durch Ausführung des folgenden SQL-Befehls überprüfen:
```
SELECT @@performance_schema;
```
Ein Ausgabewert von `1` gibt an, dass es aktiviert ist.
1. Vergewissern Sie sich, dass die Instrumentierung für den Speicher der temporären Tabellen aktiviert ist. Sie können dies durch Ausführung des folgenden SQL-Befehls überprüfen:
```
SELECT name, enabled FROM performance_schema.setup_instruments WHERE name LIKE '%memory%temptable%';
```
In der `enabled`-Spalte wird für die relevanten Einträge der Instrumentierung für den temporären Tabellenspeicher `YES` angezeigt.
**Überwachen der Verwendung temporärer Tabellen**
Wenn Sie den Anfangswert für `temptable_max_mmap` festlegen, sollten Sie mit 80 % der lokalen Speichergröße für die DB-Instance-Klasse beginnen, die Sie verwenden. Dadurch wird sichergestellt, dass die temporären Tabellen über genügend Speicherplatz für einen effizienten Betrieb verfügen und Platz für andere Festplattennutzungen auf der Instance verbleibt.
Informationen über die lokale Speichergröße für Ihre DB-Instance-Klasse finden Sie unter [Temporäre Speicherlimits für Aurora MySQLTemporäre Speicherlimits](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage).
Wenn Sie beispielsweise die DB-Instance-Klasse db.r5.large verwenden, beträgt die lokale Speichergröße 32 GiB. In diesem Fall würden Sie den `temptable_max_mmap`-Parameter zunächst auf 80 % von 32 GiB setzen, was 25,6 GiB entspricht.
Nachdem Sie den Anfangswert von `temptable_max_mmap` festgelegt haben, führen Sie Ihren Spitzen-Workload auf den Aurora MySQL-Instances aus. Überwachen Sie die aktuelle und hohe Festplattennutzung durch die temporäre Tabelle mithilfe der folgenden SQL-Abfrage:
```
SELECT event_name, current_count, current_alloc, current_avg_alloc, high_count, high_alloc, high_avg_alloc
FROM sys.memory_global_by_current_bytes WHERE event_name LIKE 'memory/temptable/%';
```
Diese Abfrage ruft die folgenden Informationen ab:
+ `event_name` – Der Name des Ereignisses für den temporären Tabellenspeicher oder die Festplattennutzung
+ `current_count` – Die aktuelle Anzahl der zugewiesenen Blöcke für den temporären Tabellenspeicher oder die Festplatte
+ `current_alloc` – Die aktuelle Menge an Speicher oder Festplatte, die temporären Tabellen zugewiesen ist
+ `current_avg_alloc` – Die aktuelle durchschnittliche Größe des temporären Tabellenspeichers oder der Festplattenblöcke
+ `high_count` – Die höchste Anzahl des zugewiesenen temporären Tabellenspeichers oder der Festplattenblöcke
+ `high_alloc` – Die größte Menge an Speicher oder Festplatte, die temporären Tabellen zugewiesen ist
+ `high_avg_alloc` – Die höchste durchschnittliche Größe des temporären Tabellenspeichers oder der Festplattenblöcke
Wenn Ihre Abfragen bei Verwendung dieser Einstellung mit dem Fehler „Table is full“ fehlschlagen, bedeutet dies, dass Ihr Workload mehr Festplattenspeicher für temporäre Tabellenoperationen benötigt. In diesem Fall sollten Sie erwägen, die Größe Ihrer DB-Instance auf eine mit mehr lokalem Speicherplatz zu erhöhen.
**Den optimalen `temptable_max_mmap`-Wert festlegen**
Gehen Sie wie folgt vor, um die richtige Größe für den `temptable_max_mmap`-Parameter festzulegen und ihn zu überwachen:
1. Überprüfen Sie die Ausgabe der vorherigen Abfrage und ermitteln Sie die maximale Festplattennutzung durch temporäre Dateien wie in der `high_alloc`-Spalte angegeben.
1. Passen Sie, basierend auf der maximalen Festplattennutzung durch temporäre Dateien, den `temptable_max_mmap`-Parameter in der DB-Parametergruppe für Ihre DB-Instances von Aurora MySQL an.
Stellen Sie den Wert so ein, dass er etwas höher ist als die maximale Festplattennutzung durch temporäre Tabellen, um eine zukünftige Zunahme zu berücksichtigen.
1. Wenden Sie die Änderungen an der Parametergruppe auf Ihre DB-Instances an.
1. Überwachen Sie die Festplattennutzung der temporären Tabelle während des Spitzen-Workloads erneut, um sicherzustellen, dass der neue `temptable_max_mmap`-Wert angemessen ist.
1. Wiederholen Sie die vorherigen Schritte bei Bedarf, um den `temptable_max_mmap`-Parameter zu optimieren.
## Vom Benutzer erstellte (explizite) temporäre Tabellen auf Reader-DB-Instances
Sie können explizite temporäre Tabellen erstellen, indem Sie das Schlüsselwort `TEMPORARY` in Ihrer Anweisung `CREATE TABLE` verwenden. Explizite temporäre Tabellen werden auf der Writer-DB-Instance in einem Aurora-DB-Cluster unterstützt. Sie können auch explizite temporäre Tabellen für Reader DB-Instances verwenden. Die Tabellen können jedoch die Verwendung der InnoDB-Speicher-Engine nicht erzwingen.
Um Fehler beim Erstellen expliziter temporärer Tabellen auf Reader-DB-Instances von Aurora MySQL zu vermeiden, stellen Sie sicher, dass alle `CREATE TEMPORARY TABLE`-Anweisungen mit einer der folgenden Methoden ausgeführt werden:
+ Verzichten Sie auf die Angabe der `ENGINE=InnoDB`-Klausel.
+ Legen Sie den SQL-Modus nicht auf `NO_ENGINE_SUBSTITUTION` fest.
## Fehler bei der Erstellung temporärer Tabellen und Abhilfemaßnahmen
Der Fehler, den Sie erhalten, ist unterschiedlich, je nachdem, ob Sie ein einfache `CREATE TEMPORARY TABLE`-Aussage oder die Variation `CREATE TEMPORARY TABLE AS SELECT` verwenden. Das folgende Beispiel zeigt die Reihenfolge der verschiedenen Typen:
Dieses temporäre Tabellenverhalten gilt nur für schreibgeschützte Instances. Dieses erste Beispiel bestätigt, dass es sich um die Art von Instance handelt, mit der die Sitzung verbunden ist.
```
mysql> select @@innodb_read_only;
+--------------------+
| @@innodb_read_only |
+--------------------+
| 1 |
+--------------------+
```
Für einfache `CREATE TEMPORARY TABLE`-Anweisungen schlägt die Anweisung fehl, wenn der `NO_ENGINE_SUBSTITUTION`-SQL-Modus aktiviert ist. Wenn `NO_ENGINE_SUBSTITUTION` deaktiviert wird (Standardeinstellung), wird die entsprechende Engine-Ersetzung vorgenommen und die temporäre Tabelle wird erfolgreich erstellt.
```
mysql> set sql_mode = 'NO_ENGINE_SUBSTITUTION';
mysql> CREATE TEMPORARY TABLE tt2 (id int) ENGINE=InnoDB;
ERROR 3161 (HY000): Storage engine InnoDB is disabled (Table creation is disallowed).
mysql> SET sql_mode = '';
mysql> CREATE TEMPORARY TABLE tt4 (id int) ENGINE=InnoDB;
mysql> SHOW CREATE TABLE tt4\G
*************************** 1. row ***************************
Table: tt4
Create Table: CREATE TEMPORARY TABLE `tt4` (
`id` int DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
```
Für `CREATE TEMPORARY TABLE AS SELECT`-Anweisungen schlägt die Anweisung fehl, wenn der SQL-Modus `NO_ENGINE_SUBSTITUTION` aktiviert ist. Wenn `NO_ENGINE_SUBSTITUTION` deaktiviert wird (Standardeinstellung), wird die entsprechende Engine-Ersetzung vorgenommen und die temporäre Tabelle wird erfolgreich erstellt.
```
mysql> set sql_mode = 'NO_ENGINE_SUBSTITUTION';
mysql> CREATE TEMPORARY TABLE tt1 ENGINE=InnoDB AS SELECT * FROM t1;
ERROR 3161 (HY000): Storage engine InnoDB is disabled (Table creation is disallowed).
mysql> SET sql_mode = '';
mysql> show create table tt3;
+-------+----------------------------------------------------------+
| Table | Create Table |
+-------+----------------------------------------------------------+
| tt3 | CREATE TEMPORARY TABLE `tt3` (
`id` int DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci |
+-------+----------------------------------------------------------+
1 row in set (0.00 sec)
```
Weitere Informationen zu den Speicheraspekten und den Auswirkungen temporärer Tabellen auf die Leistung in Aurora MySQL Version 3 finden Sie im Blogbeitrag [Verwenden Sie die TempTable Speicher-Engine auf Amazon RDS for MySQL und Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/).
# Vergleich von Aurora-MySQL-Version 2 und Aurora-MySQL-Version 3
Verwenden Sie Folgendes, um mehr über Änderungen zu erfahren, die Sie beachten sollten, wenn Sie Ihren Aurora-MySQL-Version 2-Cluster auf Version 3 aktualisieren.
**Topics**
+ [Unterstützung der Atomic Data Definition Language (DDL)](#AuroraMySQL.Compare-v2-v3-atomic-ddl)
+ [Funktionsunterschiede zwischen Aurora MySQL Version 2 und 3](#AuroraMySQL.Compare-v2-v3-features)
+ [Unterstützung für Instance-Klassen](#AuroraMySQL.mysql80-instance-classes)
+ [Parameteränderungen für Aurora MySQL Version 3](#AuroraMySQL.mysql80-parameter-changes)
+ [Statusvariablen.](#AuroraMySQL.mysql80-status-vars)
+ [Inklusive Sprachänderungen für Aurora MySQL Version 3](#AuroraMySQL.8.0-inclusive-language)
+ [AUTO\$1INCREMENT-Werte](#AuroraMySQL.mysql80-autoincrement)
+ [Binäre Protokoll-Replikation](#AuroraMySQL.mysql80-binlog)
## Unterstützung der Atomic Data Definition Language (DDL)
Eine der größten Änderungen von MySQL 5.7 auf 8.0 ist die Einführung des [Atomic Data Dictionary](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html). Vor MySQL 8.0 verwendete das MySQL-Datenwörterbuch einen dateibasierten Ansatz, um Metadaten wie Tabellendefinitionen (.frm), Trigger (.trg) und Funktionen getrennt von den Metadaten der Speicher-Engine (wie denen von InnoDB) zu speichern. Dabei gab es einige Probleme, darunter das Risiko, dass Tabellen „[verwaist](https://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting-datadict.html)“ wurden, wenn während einer DDL-Operation etwas Unerwartetes passierte, wodurch die dateibasierten und die Speicher-Engine-Metadaten nicht mehr synchron waren.
Zum Beheben dieses Problems wurde mit MySQL 8.0 das Atomic Data Dictionary eingeführt, das alle Metadaten in einer Reihe interner InnoDB-Tabellen im `mysql`-Schema speichert. Diese neue Architektur bietet eine transaktionale, [ACID](https://en.wikipedia.org/wiki/ACID)-konforme Methode zur Verwaltung von Datenbankmetadaten und löst damit das „atomare DDL“-Problem des alten dateibasierten Ansatzes. Weitere Informationen zum Atomic Data Dictionary finden Sie unter [Entfernung des dateibasierten Metadatenspeichers](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html) und [Unterstützung von Atomic-Datendefinitionsanweisungen](https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html) im *MySQL-Referenzhandbuch*.
Aufgrund dieser Architekturänderung müssen Sie beim Upgrade von Aurora-MySQL-Version 2 auf Version 3 Folgendes beachten:
+ Die dateibasierten Metadaten von Version 2 müssen während des Upgrade-Prozesses auf Version 3 zu den neuen Datenwörterbuchtabellen migriert werden. Je nachdem, wie viele Datenbankobjekte migriert werden, kann dies einige Zeit dauern.
+ Durch die Änderungen wurden auch einige neue Inkompatibilitäten eingeführt, die möglicherweise behoben werden müssen, bevor Sie ein Upgrade von MySQL 5.7 auf 8.0 durchführen können. Zum Beispiel enthält 8.0 einige neue reservierte Schlüsselwörter, die zu Konflikten mit bestehenden Datenbankobjektnamen führen könnten.
Um Ihnen zu helfen, diese Inkompatibilitäten vor dem Upgrade der Engine zu identifizieren, führt Aurora MySQL vor der Durchführung des Datenwörterbuch-Upgrades eine Reihe von Upgrade-Kompatibilitätsprüfungen (Vorabprüfungen) durch, um festzustellen, ob Ihr Datenbankwörterbuch inkompatible Objekte enthält. Weitere Informationen zu den Vorabprüfungen finden Sie unter [Vorabprüfungen für Hauptversions-Upgrades von Aurora MySQL](AuroraMySQL.upgrade-prechecks.md).
## Funktionsunterschiede zwischen Aurora MySQL Version 2 und 3
Die folgenden Amazon-Aurora-MySQL-Funktionen werden in Aurora MySQL for MySQL 5.7 unterstützt, in Aurora MySQL for MySQL 8.0 derzeit jedoch nicht.
+ Sie können Aurora-MySQL-Version 3 nicht für Aurora Serverless v1-Cluster verwenden. Aurora-MySQL-Version 3 arbeitet mit Aurora Serverless v2.
+ Der Labor-Modus gilt nicht für Aurora-MySQL-Version 3. In Aurora-MySQL-Version 3 gibt es keine Labormodusfunktionen. Instant DDL ersetzt die schnelle Online-DDL-Funktion, die früher im Labormodus verfügbar war. Ein Beispiel finden Sie unter [Sofortige DDL (Aurora MySQL Version 3)](AuroraMySQL.Managing.FastDDL.md#AuroraMySQL.mysql80-instant-ddl).
+ Der Abfrage-Cache wird aus der Community MySQL 8.0 und auch aus Aurora MySQL Version 3 entfernt.
+ Aurora MySQL Version 3 ist mit der MySQL-Hash-Join-Funktion der Community kompatibel. Die Aurora-spezifische Implementierung von Hash-Joins in Aurora MySQL Version 2 wird nicht verwendet. Informationen zur Verwendung von Hash-Joins mit Aurora-Parallelabfrage finden Sie unter[Hash-Join für parallele Abfrage-Cluster aktivieren](aurora-mysql-parallel-query-enabling.md#aurora-mysql-parallel-query-enabling-hash-join)und[Aurora-MySQL-Hinweise](AuroraMySQL.Reference.Hints.md)aus. Allgemeine Nutzungsinformationen zu Hash-Joins finden Sie unter[Hash Join-Optimierung](https://dev.mysql.com/doc/refman/8.0/en/hash-joins.html)im*MySQL-Referenzhandbuch*aus.
+ Die`mysql.lambda_async`Die gespeicherte Prozedur, die in Aurora MySQL Version 2 veraltet war, wird in Version 3 entfernt. Verwenden Sie für Version 3 die asynchrone Funktion`lambda_async`Stattdessen.
+ Der Standardzeichensatz in Aurora MySQL Version 3 ist`utf8mb4`aus. In Aurora MySQL Version 2 war der Standardzeichensatz`latin1`aus. Weitere Informationen zu diesem Zeichensatz finden Sie unter[Der utf8mb4-Zeichensatz (UTF-8-Unicode-Kodierung mit 4 Bytes)](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb4.html)im*MySQL-Referenzhandbuch*aus.
Einige Aurora MySQL-Funktionen stehen für bestimmte Kombinationen vonAWSVersion der Region und der DB-Engine Details hierzu finden Sie unter [Unterstützte Funktionen in Amazon Aurora by AWS-Region und der Aurora-DB-Engine](Concepts.AuroraFeaturesRegionsDBEngines.grids.md).
## Unterstützung für Instance-Klassen
Aurora-MySQL-Version 3 unterstützt einen anderen Satz von Instance-Klassen als Aurora-MySQL-Version 2:
+ Für größere Instances können Sie die modernen Instance-Klassen wie`db.r5`, `db.r6g` und `db.x2g` verwenden.
+ Für kleinere Instances können Sie die modernen Instance-Klassen wie `db.t3` und `db.t4g` verwenden.
**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](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium).
Die folgenden Instance-Klassen aus Aurora-MySQL-Version 2 sind für Aurora-MySQL-Version 3 nicht verfügbar:
+ `db.r4`
+ `db.r3`
+ `db.t3.small`
+ `db.t2`
Überprüfen Sie Ihre Verwaltungsskripte auf CLI-Anweisungen, die DB-Instances von Aurora MySQL erstellen. Hardcode-Instance-Klassennamen, die für Aurora-MySQL-Version 3 nicht verfügbar sind. Ändern Sie ggf. die Namen der Instance-Klasse zu solchen, die Aurora-MySQL-Version 3 unterstützt.
**Tipp**
Um die Instance-Klassen zu überprüfen, die Sie für eine bestimmte Kombination von Aurora MySQL-Version und AWS-Region verwenden können, verwenden Sie den `describe-orderable-db-instance-options` AWS CLI-Befehl.
Ausführliche Einzelheiten zu Aurora-Instance-Klassen finden Sie unter [Amazon Aurora Aurora-DB-Instance-Klassen](Concepts.DBInstanceClass.md).
## Parameteränderungen für Aurora MySQL Version 3
Aurora MySQL Version 3 enthält neue Konfigurationsparameter auf Cluster-Ebene und Instance-Ebene. Aurora MySQL Version 3 entfernt auch einige Parameter, die in Aurora MySQL Version 2 vorhanden waren. Einige Parameternamen werden infolge der Initiative zur inklusiven Sprache geändert. Aus Gründen der Abwärtskompatibilität können Sie die Parameterwerte weiterhin entweder mit den alten Namen oder den neuen Namen abrufen. Sie müssen jedoch die neuen Namen verwenden, um Parameterwerte in einer benutzerdefinierten Parametergruppe anzugeben.
In Aurora MySQL Version 3 ist der Wert des`lower_case_table_names`-Parameter wird zum Zeitpunkt der Erstellung des Clusters dauerhaft festgelegt. Wenn Sie für diese Option einen nicht standardmäßigen Wert verwenden, richten Sie Ihre benutzerdefinierte Parametergruppe Aurora MySQL Version 3 vor dem Upgrade ein. Geben Sie dann die Parametergruppe während des Wiederherstellungsvorgangs „Cluster wiederherstellen“ oder „Snapshot wiederherstellen“ an.
**Anmerkung**
Bei einer auf Aurora MySQL basierenden globalen Aurora-Datenbank können Sie kein direktes Upgrade von Aurora-MySQL-Version 2 zu Version 3 durchführen, wenn der Parameter `lower_case_table_names` aktiviert ist. Verwenden Sie stattdessen die Snapshot-Wiederherstellungsmethode.
In Aurora-MySQL-Version 3 gelten die Parameter `init_connect` und `read_only` nicht für Benutzer, die über die `CONNECTION_ADMIN`-Berechtigung verfügen. Dies schließt den Aurora-Hauptbenutzer ein. Weitere Informationen finden Sie unter [Rollenbasiertes Berechtigungsmodell](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model).
Eine Liste aller Aurora-MySQL-Clusterparameter finden Sie unter [Parameter auf Cluster-Ebene](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Cluster). Die Tabelle umfasst alle Parameter aus Aurora-MySQL-Version 2 und 3. Die Tabelle enthält Hinweise dazu, welche Parameter in Aurora-MySQL-Version 3 neu sind oder aus Aurora-MySQL-Version 3 entfernt wurden.
Eine vollständige Liste der Aurora-MySQL-Instance-Parameter finden Sie unter [Parameter auf Instance-Ebene](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Instance). Die Tabelle umfasst alle Parameter aus Aurora-MySQL-Version 2 und 3. Die Tabelle enthält Hinweise dazu, welche Parameter in Aurora-MySQL-Version 3 neu sind und welche Parameter aus Aurora-MySQL-Version 3 entfernt wurden. Sie enthält auch Hinweise dazu, welche Parameter in früheren Versionen modifizierbar waren, aber nicht Aurora-MySQL´-Version 3.
Weitere Informationen zu geänderten Parameternamen finden Sie unter [Inklusive Sprachänderungen für Aurora MySQL Version 3](#AuroraMySQL.8.0-inclusive-language).
## Statusvariablen.
Informationen zu Statusvariablen, die nicht auf Aurora MySQL anwendbar sind, finden Sie unter[MySQL-Statusvariablen, die nicht für Aurora MySQL gelten](AuroraMySQL.Reference.GlobalStatusVars.md#AuroraMySQL.Reference.StatusVars.Inapplicable)aus.
## Inklusive Sprachänderungen für Aurora MySQL Version 3
Aurora MySQL Version 3 ist mit Version 8.0.23 aus der MySQL Community Edition kompatibel. Aurora MySQL Version 3 enthält auch Änderungen von MySQL 8.0.26 in Bezug auf Schlüsselwörter und Systemschemas für inklusive Sprache. Zum Beispiel, das`SHOW REPLICA STATUS`Befehl wird jetzt bevorzugt statt`SHOW SLAVE STATUS`aus.
Die folgenden Amazon CloudWatch-Metriken haben neue Namen in Aurora MySQL Version 3.
In Aurora MySQL Version 3 sind nur die neuen Metriknamen verfügbar. Stellen Sie sicher, dass Sie alle Alarme oder andere Automatisierungen aktualisieren, die auf Metriknamen beruhen, wenn Sie auf Aurora MySQL Version 3 aktualisieren.
| Alter Name | Neuer Name |
| --- | --- |
| ForwardingMasterDMLLatency | ForwardingWriterDMLLatency |
| ForwardingMasterOpenSessions | ForwardingWriterOpenSessions |
| AuroraDMLRejectedMasterFull | AuroraDMLRejectedWriterFull |
| ForwardingMasterDMLThroughput | ForwardingWriterDMLThroughput |
Die folgenden Statusvariablen haben neue Namen in Aurora MySQL Version 3.
Aus Gründen der Kompatibilität können Sie beide Namen in der ersten Version 3 von Aurora MySQL verwenden. Die alten Statusvariablennamen sollen in einer zukünftigen Version entfernt werden.
| Name, der entfernt werden soll | Neuer oder bevorzugter Name |
| --- | --- |
| Aurora\$1fwd\$1master\$1dml\$1stmt\$1duration | Aurora\$1fwd\$1writer\$1dml\$1stmt\$1duration |
| Aurora\$1fwd\$1master\$1dml\$1stmt\$1count | Aurora\$1fwd\$1writer\$1dml\$1stmt\$1count |
| Aurora\$1fwd\$1master\$1select\$1stmt\$1duration | Aurora\$1fwd\$1writer\$1select\$1stmt\$1duration |
| Aurora\$1fwd\$1master\$1select\$1stmt\$1count | Aurora\$1fwd\$1writer\$1select\$1stmt\$1count |
| Aurora\$1fwd\$1master\$1errors\$1session\$1timeout | Aurora\$1fwd\$1writer\$1errors\$1session\$1timeout |
| Aurora\$1fwd\$1master\$1open\$1sessions | Aurora\$1fwd\$1writer\$1open\$1sessions |
| Aurora\$1fwd\$1master\$1errors\$1session\$1limit | Aurora\$1fwd\$1writer\$1errors\$1session\$1limit |
| Aurora\$1fwd\$1master\$1errors\$1rpc\$1timeout | Aurora\$1fwd\$1writer\$1errors\$1rpc\$1timeout |
Die folgenden Konfigurationsparameter haben neue Namen in Aurora MySQL Version 3.
Aus Gründen der Kompatibilität können Sie die Parameterwerte im `mysql`-Client unter Verwendung eines der beiden Namen in der ersten Version 3 von Aurora MySQL prüfen. Beim Ändern der Werte in einer benutzerdefinierten Parametergruppe können Sie nur die neuen Namen verwenden. Die alten Parameternamen werden in einer zukünftigen Version entfernt.
| Name, der entfernt werden soll | Neuer oder bevorzugter Name |
| --- | --- |
| aurora\$1fwd\$1master\$1idle\$1timeout | aurora\$1fwd\$1writer\$1idle\$1timeout |
| aurora\$1fwd\$1master\$1max\$1connections\$1pct | aurora\$1fwd\$1writer\$1max\$1connections\$1pct |
| master\$1verify\$1checksum | source\$1verify\$1checksum |
| sync\$1master\$1info | sync\$1source\$1info |
| init\$1slave | init\$1replica |
| rpl\$1stop\$1slave\$1timeout | rpl\$1stop\$1replica\$1timeout |
| log\$1slow\$1slave\$1statements | log\$1slow\$1replica\$1statements |
| slave\$1max\$1allowed\$1packet | replica\$1max\$1allowed\$1packet |
| slave\$1compressed\$1protocol | replica\$1compressed\$1protocol |
| slave\$1exec\$1mode | replica\$1exec\$1mode |
| slave\$1type\$1conversions | replica\$1type\$1conversions |
| slave\$1sql\$1verify\$1checksum | replica\$1sql\$1verify\$1checksum |
| slave\$1parallel\$1type | replica\$1parallel\$1type |
| slave\$1preserve\$1commit\$1order | replica\$1preserve\$1commit\$1order |
| log\$1slave\$1updates | log\$1replica\$1updates |
| slave\$1allow\$1batching | replica\$1allow\$1batching |
| slave\$1load\$1tmpdir | replica\$1load\$1tmpdir |
| slave\$1net\$1timeout | replica\$1net\$1timeout |
| sql\$1slave\$1skip\$1counter | sql\$1replica\$1skip\$1counter |
| slave\$1skip\$1errors | replica\$1skip\$1errors |
| slave\$1checkpoint\$1period | replica\$1checkpoint\$1period |
| slave\$1checkpoint\$1group | replica\$1checkpoint\$1group |
| slave\$1transaction\$1retries | replica\$1transaction\$1retries |
| slave\$1parallel\$1workers | replica\$1parallel\$1workers |
| slave\$1pending\$1jobs\$1size\$1max | replica\$1pending\$1jobs\$1size\$1max |
| pseudo\$1slave\$1mode | pseudo\$1replica\$1mode |
Die folgenden gespeicherten Prozeduren haben neue Namen in Aurora MySQL Version 3.
Aus Gründen der Kompatibilität können Sie beide Namen in der ersten Version 3 von Aurora MySQL verwenden. Die alten Prozedurnamen sollen in einer zukünftigen Version entfernt werden.
| Name, der entfernt werden soll | Neuer oder bevorzugter Name |
| --- | --- |
| mysql.rds\$1set\$1master\$1auto\$1position | mysql.rds\$1set\$1source\$1auto\$1position |
| mysql.rds\$1set\$1external\$1master | mysql.rds\$1set\$1external\$1source |
| mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position | mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position |
| mysql.rds\$1reset\$1external\$1master | mysql.rds\$1reset\$1external\$1source |
| mysql.rds\$1next\$1master\$1log | mysql.rds\$1next\$1source\$1log |
## AUTO\$1INCREMENT-Werte
In Aurora MySQL Version 3 bewahrt Aurora`AUTO_INCREMENT`Wert für jede Tabelle, wenn jede DB-Instance neu gestartet wird. In Aurora MySQL Version 2 wird`AUTO_INCREMENT`Der Wert wurde nach einem Neustart nicht beibehalten.
Die`AUTO_INCREMENT`-Wert wird nicht beibehalten, wenn Sie einen neuen Cluster einrichten, indem Sie aus einem Snapshot wiederherstellen, eine Point-in-Time-Wiederherstellung durchführen und einen Cluster klonen. In diesen Fällen wird die`AUTO_INCREMENT`value wird basierend auf dem größten Spaltenwert in der Tabelle zum Zeitpunkt der Erstellung des Snapshots auf den Wert initialisiert. Dieses Verhalten ist anders als in RDS für MySQL 8.0, wo der `AUTO_INCREMENT`-Wert während dieser Vorgänge beibehalten wird.
## Binäre Protokoll-Replikation
In der MySQL 8.0 Community Edition ist die Replikation des Binärprotokolls standardmäßig aktiviert. In Aurora MySQL Version 3 ist die Replikation des binären Protokolls standardmäßig deaktiviert.
**Tipp**
Wenn Ihre Hochverfügbarkeitsanforderungen durch die integrierten Replikationsfunktionen von Aurora erfüllt werden, können Sie die Replikation von Binärprotokollen deaktiviert lassen. Auf diese Weise können Sie den Leistungsaufwand der Binärprotokollreplikation vermeiden. Sie können auch die zugehörige Überwachung und Fehlerbehebung vermeiden, die für die Verwaltung der Binärprotokollreplikation erforderlich sind.
Aurora unterstützt die Binärprotokollreplikation von einer MySQL 5.7 kompatiblen Quelle zu Aurora MySQL Version 3. Das Quellsystem kann ein Aurora MySQL-DB-Cluster, eine RDS für MySQL-DB-Instance oder eine lokale MySQL-DB-Instance sein.
Wie bei der Community MySQL unterstützt Aurora MySQL die Replikation von einer Quelle, auf der eine bestimmte Version ausgeführt wird, zu einem Ziel, auf dem dieselbe Hauptversion oder eine höhere Hauptversion ausgeführt wird. Beispielsweise wird die Replikation von einem MySQL 5.6 kompatiblen System auf Aurora MySQL Version 3 nicht unterstützt. Die Replikation von Aurora MySQL Version 3 auf ein mit MySQL 5.7 kompatibles oder MySQL 5.6—kompatibles System wird nicht unterstützt. Einzelheiten zur Verwendung der Binärprotokollreplikation finden Sie unter[Replizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation)](AuroraMySQL.Replication.MySQL.md)aus.
Aurora MySQL Version 3 enthält Verbesserungen der Binärprotokollreplikation in der Community MySQL 8.0, z. B. gefilterte Replikation. Weitere Informationen zu den Verbesserungen der Community MySQL 8.0 finden Sie unter[So bewerten Server Replikationsfilterregeln](https://dev.mysql.com/doc/refman/8.0/en/replication-rules.html)im*MySQL-Referenzhandbuch*aus.
### Transaktionskomprimierung für die Binärprotokollreplikation
Informationen zur Verwendung zur Binärprotokollkomprimierung finden Sie unter[Binärprotokoll-Transaktionskomprimierung](https://dev.mysql.com/doc/refman/8.0/en/binary-log-transaction-compression.html)im MySQL-Referenzhandbuch.
Die folgenden Einschränkungen gelten für die Binärprotokollkomprimierung in Aurora-MySQL-Version 3:
+ Transaktionen, deren binäre Protokolldaten größer als die maximal zulässige Paketgröße sind, werden nicht komprimiert. Dies gilt unabhängig davon, ob die Einstellung für die Komprimierung des binären Protokolls in Aurora MySQL aktiviert ist. Solche Transaktionen werden repliziert, ohne komprimiert zu werden.
+ Wenn Sie einen Konnektor für Change Data Capture (CDC) verwenden, der MySQL 8.0 noch nicht unterstützt, können Sie diese Funktion nicht verwenden. Es wird empfohlen, alle Konnektoren von Drittanbietern gründlich mit der Binärprotokollkomprimierung zu testen. Diese Tests sollten ausgeführt werden, bevor Sie die Binlog-Komprimierung in Systemen aktivieren, die Binlog-Replikation für CDC verwenden.
# Vergleich von Aurora-MySQL-Version 3 und MySQL 8.0 Community Edition
Sie können die folgenden Informationen verwenden, um mehr über die Änderungen zu erfahren, die Sie beachten müssen, wenn Sie von einem anderen MySQL 8.0-kompatiblen System zu Aurora-MySQL-Version 3 konvertieren.
Im Allgemeinen unterstützt Aurora MySQL Version 3 den Feature-Set der Community MySQL 8.0.23. Einige neue Funktionen der MySQL 8.0 Community Edition gelten nicht für Aurora MySQL. Einige dieser Funktionen sind mit einigen Aurora-Aspekten, wie der Aurora-Speicherarchitektur, nicht kompatibel. Andere Funktionen sind nicht erforderlich, da der Amazon-RDS-Verwaltungsservice gleichwertige Funktionen bietet. Die folgenden Funktionen in der Community MySQL 8.0 werden in Aurora-MySQL-Version 3 nicht unterstützt oder funktionieren anders.
Die Versionshinweise für alle Versionen von Aurora MySQL Version 3 finden Sie unter [Aktualisierungen der Datenbank-Engine für Amazon Aurora MySQL Version 3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html) in den *Versionshinweisen für Aurora MySQL*.
**Topics**
+ [MySQL-8.0-Funktionen sind in Aurora-MySQL-Version 3 nicht verfügbar](#AuroraMySQL.Compare-80-v3-features)
+ [Rollenbasiertes Berechtigungsmodell](#AuroraMySQL.privilege-model)
+ [Finden der Datenbankserver-ID](#AuroraMySQL.server-id)
+ [Authentifizierung](#AuroraMySQL.mysql80-authentication)
## MySQL-8.0-Funktionen sind in Aurora-MySQL-Version 3 nicht verfügbar
Die folgenden Funktionen der Community MySQL 8.0 sind in Aurora MySQL Version 3 nicht verfügbar oder funktionieren anders.
+ Ressourcengruppen und zugehörige SQL-Anweisungen werden in Aurora MySQL nicht unterstützt.
+ Aurora MySQL unterstützt keine benutzerdefinierten Undo-Tablespaces und die dazugehörigen SQL-Anweisungen wie `CREATE UNDO TABLESPACE`, `ALTER UNDO TABLESPACE ... SET INACTIVE` und `DROP UNDO TABLESPACE`.
+ Aurora MySQL unterstützt keine Undo-Tablespace-Kürzungen für Aurora-MySQL-Versionen unter 3.06. In Aurora-MySQL-Version 3.06 und höher werden [automatisierte Undo-Tablespace-Kürzungen](https://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html#truncate-undo-tablespace) unterstützt.
+ Das Plugin für die Passwortvalidierung wird unterstützt.
+ Sie können die Einstellungen von MySQL-Plugins nicht ändern, einschließlich des Plugins für die Passwortvalidierung.
+ Das X-Plugin wird nicht unterstützt.
+ Multisource-Replikation wird nicht unterstützt.
## Rollenbasiertes Berechtigungsmodell
Mit Aurora MySQL Version 3 können Sie die Tabellen im`mysql`-Datenbank direkt. Insbesondere können Sie Benutzer nicht einrichten, indem Sie in die`mysql.user`-Tabelle Stattdessen verwenden Sie SQL-Anweisungen, um rollenbasierte Berechtigungen zu gewähren. Sie können auch keine anderen Objekte wie gespeicherte Prozeduren in der `mysql`-Datenbank erstellen. Sie können immer noch die `mysql`-Tabellen abfragen. Wenn Sie die Binärprotokollreplikation verwenden, werden Änderungen direkt am`mysql`Tabellen im Quellcluster werden nicht auf den Zielcluster repliziert.
In einigen Fällen verwendet Ihre Anwendung möglicherweise Verknüpfungen, um Benutzer oder andere Objekte zu erstellen, indem Sie sie in die`mysql`-Tabellen Wenn ja, ändern Sie Ihren Anwendungscode, um die entsprechenden Anweisungen wie `CREATE USER` zu verwenden. Wenn Ihre Anwendung gespeicherte Prozeduren oder andere Objekte in der `mysql`-Datenbank erstellt, verwenden Sie stattdessen eine andere Datenbank.
Um Metadaten für Datenbankbenutzer während der Migration aus einer externen MySQL-Datenbank zu exportieren, können Sie einen MySQL-Shell-Befehl anstelle von `mysqldump` verwenden. Weitere Informationen finden Sie unter [Dienstprogramme für Instance-, Schema- und Tabellen-Dumps](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html#mysql-shell-utilities-dump-about).
Um die Verwaltung von Berechtigungen für viele Benutzer oder Anwendungen zu vereinfachen, können Sie`CREATE ROLE`-Anweisung zum Erstellen einer Rolle mit einer Reihe von Berechtigungen. Dann können Sie die`GRANT`und`SET ROLE`-Anweisungen und die`current_role`Funktion, um Benutzern oder Anwendungen Rollen zuzuweisen, die aktuelle Rolle zu wechseln und zu überprüfen, welche Rollen in Kraft sind. Weitere Informationen zum rollenbasierten Berechtigungssystem in MySQL 8.0 finden Sie unter [Verwenden von Rollen](https://dev.mysql.com/doc/refman/8.0/en/roles.html) im MySQL-Referenzhandbuch.
**Wichtig**
Wir empfehlen Ihnen, den Hauptbenutzer nicht direkt in Ihren Anwendungen zu verwenden. Bleiben Sie stattdessen bei der bewährten Methode, einen Datenbankbenutzer zu verwenden, der mit den Mindestberechtigungen erstellt wurde, die für Ihre Anwendung erforderlich sind.
**Topics**
+ [rds\$1superuser\$1role](#AuroraMySQL.privilege-model.rds_superuser_role)
+ [Benutzer zur Berechtigungsprüfung für die Replikation von Binärprotokollen](#AuroraMySQL.privilege-model.binlog)
+ [Rollen für den Zugriff auf andere AWS Dienste](#AuroraMySQL.privilege-model.other)
### rds\$1superuser\$1role
Aurora-MySQL-Version 3 enthält eine spezielle Rolle, die alle folgenden Berechtigungen besitzt. Der Name der Rolle lautet `rds_superuser_role`. Dem primären Administratorbenutzer für jeden Cluster wurde diese Rolle bereits gewährt. Die`rds_superuser_role`enthält die folgenden Berechtigungen für alle Datenbankobjekte:
+ `ALTER`
+ `APPLICATION_PASSWORD_ADMIN`
+ `ALTER ROUTINE`
+ `CONNECTION_ADMIN`
+ `CREATE`
+ `CREATE ROLE`
+ `CREATE ROUTINE`
+ `CREATE TEMPORARY TABLES`
+ `CREATE USER`
+ `CREATE VIEW`
+ `DELETE`
+ `DROP`
+ `DROP ROLE`
+ `EVENT`
+ `EXECUTE`
+ `FLUSH_OPTIMIZER_COSTS` (Aurora-MySQL-Version 3.09 und höher)
+ `FLUSH_STATUS` (Aurora-MySQL-Version 3.09 und höher)
+ `FLUSH_TABLES` (Aurora-MySQL-Version 3.09 und höher)
+ `FLUSH_USER_RESOURCES` (Aurora-MySQL-Version 3.09 und höher)
+ `INDEX`
+ `INSERT`
+ `LOCK TABLES`
+ `PROCESS`
+ `REFERENCES`
+ `RELOAD`
+ `REPLICATION CLIENT`
+ `REPLICATION SLAVE`
+ `ROLE_ADMIN`
+ `SET_USER_ID`
+ `SELECT`
+ `SHOW DATABASES`
+ `SHOW_ROUTINE` (Aurora-MySQL-Version 3.04 und höher)
+ `SHOW VIEW`
+ `TRIGGER`
+ `UPDATE`
+ `XA_RECOVER_ADMIN`
Die Rollendefinition umfasst auch`WITH GRANT OPTION`damit ein Administratorbenutzer diese Rolle anderen Benutzern gewähren kann. Insbesondere muss der Administrator alle Berechtigungen erteilen, die zur Durchführung der Binärprotokollreplikation mit dem Aurora MySQL-Cluster als Ziel erforderlich sind.
**Tipp**
Um die vollständigen Details der Berechtigungen anzuzeigen, geben Sie die folgenden Anweisungen ein.
```
SHOW GRANTS FOR rds_superuser_role@'%';
SHOW GRANTS FOR name_of_administrative_user_for_your_cluster@'%';
```
### Benutzer zur Berechtigungsprüfung für die Replikation von Binärprotokollen
Aurora-MySQL-Version 3 enthält einen Benutzer zur Berechtigungsprüfung für die Replikation von Binärprotokollen (Binlog), `rdsrepladmin_priv_checks_user`. Zusätzlich zu den Berechtigungen einer `rds_superuser_role` verfügt dieser Benutzer über die `replication_applier`-Berechtigung.
Wenn Sie die Binlog-Replikation aktivieren, indem Sie die gespeicherte Prozedur `mysql.rds_start_replication` aufrufen, wird `rdsrepladmin_priv_checks_user` erstellt.
Der Benutzer `rdsrepladmin_priv_checks_user@localhost` ist ein reservierter Benutzer. Ändern Sie ihn nicht.
### Rollen für den Zugriff auf andere AWS Dienste
Aurora MySQL Version 3 enthält Rollen, mit denen Sie auf andere AWS Dienste zugreifen können. Viele dieser Rollen lassen sich alternativ zur Vergabe von Berechtigungen festlegen. Sie geben beispielsweise`GRANT AWS_LAMBDA_ACCESS TO user`INSTEAD OF`GRANT INVOKE LAMBDA ON *.* TO user`aus. Die Verfahren für den Zugriff auf andere AWS Dienste finden Sie unter[Integration von Amazon Aurora MySQL mit anderen AWS Diensten](AuroraMySQL.Integrating.md). Aurora MySQL Version 3 umfasst die folgenden Rollen im Zusammenhang mit dem Zugriff auf andere AWS Dienste:
+ `AWS_LAMBDA_ACCESS` – Eine Alternative zur `INVOKE LAMBDA`-Berechtigung. Weitere Informationen zur Nutzung finden Sie unter [Aufrufen einer Lambda-Funktion aus einem Amazon Aurora MySQL-DB-Cluster](AuroraMySQL.Integrating.Lambda.md).
+ `AWS_LOAD_S3_ACCESS` – Eine Alternative zur `LOAD FROM S3`-Berechtigung. Weitere Informationen zur Nutzung finden Sie unter [Laden von Daten in einen Amazon Aurora MySQL-DB-Cluster aus Textdateien in einem Amazon S3-Bucket](AuroraMySQL.Integrating.LoadFromS3.md).
+ `AWS_SELECT_S3_ACCESS` – Eine Alternative zur `SELECT INTO S3`-Berechtigung. Weitere Informationen zur Nutzung finden Sie unter [Speichern von Daten aus einem Amazon Aurora MySQL-DB-Cluster in Textdateien in einem Amazon S3-Bucket](AuroraMySQL.Integrating.SaveIntoS3.md).
+ `AWS_COMPREHEND_ACCESS` – Eine Alternative zur `INVOKE COMPREHEND`-Berechtigung. Weitere Informationen zur Nutzung finden Sie unter [Erteilen des Zugriffs auf Aurora Machine Learning für Datenbankbenutzer](mysql-ml.md#aurora-ml-sql-privileges).
+ `AWS_SAGEMAKER_ACCESS` – Eine Alternative zur `INVOKE SAGEMAKER`-Berechtigung. Weitere Informationen zur Nutzung finden Sie unter [Erteilen des Zugriffs auf Aurora Machine Learning für Datenbankbenutzer](mysql-ml.md#aurora-ml-sql-privileges).
+ `AWS_BEDROCK_ACCESS` – Es gibt keine entsprechende `INVOKE`-Berechtigung für Amazon Bedrock. Weitere Informationen zur Nutzung finden Sie unter [Erteilen des Zugriffs auf Aurora Machine Learning für Datenbankbenutzer](mysql-ml.md#aurora-ml-sql-privileges).
Wenn Sie Zugriff mithilfe von Rollen in Aurora MySQL Version 3 gewähren, aktivieren Sie die Rolle auch mithilfe der`SET ROLE role_name`oder`SET ROLE ALL`statement. Im folgenden Beispiel wird gezeigt, wie dies geschieht. Ersetzen Sie den entsprechenden Rollennamen für `AWS_SELECT_S3_ACCESS`.
```
# Grant role to user.
mysql> GRANT AWS_SELECT_S3_ACCESS TO 'user'@'domain-or-ip-address'
# Check the current roles for your user. In this case, the AWS_SELECT_S3_ACCESS role has not been activated.
# Only the rds_superuser_role is currently in effect.
mysql> SELECT CURRENT_ROLE();
+--------------------------+
| CURRENT_ROLE() |
+--------------------------+
| `rds_superuser_role`@`%` |
+--------------------------+
1 row in set (0.00 sec)
# Activate all roles associated with this user using SET ROLE.
# You can activate specific roles or all roles.
# In this case, the user only has 2 roles, so we specify ALL.
mysql> SET ROLE ALL;
Query OK, 0 rows affected (0.00 sec)
# Verify role is now active
mysql> SELECT CURRENT_ROLE();
+-----------------------------------------------------+
| CURRENT_ROLE() |
+-----------------------------------------------------+
| `AWS_SELECT_S3_ACCESS`@`%`,`rds_superuser_role`@`%` |
+-----------------------------------------------------+
```
## Finden der Datenbankserver-ID
Die Datenbankserver-ID (`server_id`) ist für die Replikation von Binärprotokollen (Binlog) erforderlich. Die Methode, die Server-ID zu finden, unterscheidet sich in Aurora MySQL von Community MySQL.
In Community MySQL ist die Server-ID eine Zahl, die Sie mithilfe der folgenden Syntax erhalten, während Sie beim Server angemeldet sind:
```
mysql> select @@server_id;
+-------------+
| @@server_id |
+-------------+
| 2 |
+-------------+
1 row in set (0.00 sec)
```
In Aurora MySQL ist die Server-ID die DB-Instance-ID, die Sie mithilfe der folgenden Syntax erhalten, während Sie bei der DB-Instance angemeldet sind:
```
mysql> select @@aurora_server_id;
+------------------------+
| @@aurora_server_id |
+------------------------+
| mydbcluster-instance-2 |
+------------------------+
1 row in set (0.00 sec)
```
Weitere Informationen zur Binlog-Replikation finden Sie unter [Replizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation)](AuroraMySQL.Replication.MySQL.md).
## Authentifizierung
In Community MySQL 8.0 ist das Standard-Authentifizierungs-Plugin `caching_sha2_password`. Aurora MySQL Version 3 verwendet immer noch`mysql_native_password`-Plugin. Sie können die `default_authentication_plugin`-Einstellung nicht ändern. Sie können jedoch neue Benutzer erstellen und aktuelle Benutzer sowie deren individuelle Passwörter ändern, indem Sie das neue Authentifizierungs-Plugin verwenden. Im Folgenden sehen Sie ein Beispiel.
```
mysql> CREATE USER 'testnewsha'@'%' IDENTIFIED WITH caching_sha2_password BY 'aNewShaPassword';
Query OK, 0 rows affected (0.74 sec)
```
# Upgrade auf Aurora MySQL Version 3
Weitere Informationen zu Upgrades Ihrer Datenbank von Aurora-MySQL-Version 2 zu Version 3 finden Sie unter [Aktualisieren der Hauptversion eines DB-Clusters von Amazon Aurora MySQL](AuroraMySQL.Updates.MajorVersionUpgrade.md).