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.
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.
Themen
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
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
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.
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).
-
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 unterHash-Join für parallele Abfrage-Cluster aktivierenundAurora-MySQL-Hinweiseaus. Allgemeine Nutzungsinformationen zu Hash-Joins finden Sie unterHash Join-Optimierung
imMySQL-Referenzhandbuchaus. -
Die
mysql.lambda_asyncDie gespeicherte Prozedur, die in Aurora MySQL Version 2 veraltet war, wird in Version 3 entfernt. Verwenden Sie für Version 3 die asynchrone Funktionlambda_asyncStattdessen. -
Der Standardzeichensatz in Aurora MySQL Version 3 ist
utf8mb4aus. In Aurora MySQL Version 2 war der Standardzeichensatzlatin1aus. Weitere Informationen zu diesem Zeichensatz finden Sie unterDer utf8mb4-Zeichensatz (UTF-8-Unicode-Kodierung mit 4 Bytes)imMySQL-Referenzhandbuchaus.
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.
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.r6gunddb.x2gverwenden. -
Für kleinere Instances können Sie die modernen Instance-Klassen wie
db.t3unddb.t4gverwenden.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.
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 DB-Instance-Klassen von Amazon Aurora.
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 deslower_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.
Eine Liste aller Aurora-MySQL-Clusterparameter finden Sie unter Parameter auf Cluster-Ebene. 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. 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.
Statusvariablen.
Informationen zu Statusvariablen, die nicht auf Aurora MySQL anwendbar sind, finden Sie unterMySQL-Statusvariablen, die nicht für Aurora MySQL geltenaus.
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, dasSHOW REPLICA STATUSBefehl wird jetzt bevorzugt stattSHOW SLAVE STATUSaus.
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_fwd_master_dml_stmt_duration
|
Aurora_fwd_writer_dml_stmt_duration
|
Aurora_fwd_master_dml_stmt_count
|
Aurora_fwd_writer_dml_stmt_count
|
Aurora_fwd_master_select_stmt_duration
|
Aurora_fwd_writer_select_stmt_duration
|
Aurora_fwd_master_select_stmt_count
|
Aurora_fwd_writer_select_stmt_count
|
Aurora_fwd_master_errors_session_timeout
|
Aurora_fwd_writer_errors_session_timeout
|
Aurora_fwd_master_open_sessions
|
Aurora_fwd_writer_open_sessions
|
Aurora_fwd_master_errors_session_limit
|
Aurora_fwd_writer_errors_session_limit
|
Aurora_fwd_master_errors_rpc_timeout
|
Aurora_fwd_writer_errors_rpc_timeout
|
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_fwd_master_idle_timeout
|
aurora_fwd_writer_idle_timeout
|
aurora_fwd_master_max_connections_pct
|
aurora_fwd_writer_max_connections_pct
|
master_verify_checksum
|
source_verify_checksum
|
sync_master_info
|
sync_source_info
|
init_slave
|
init_replica
|
rpl_stop_slave_timeout
|
rpl_stop_replica_timeout
|
log_slow_slave_statements
|
log_slow_replica_statements
|
slave_max_allowed_packet
|
replica_max_allowed_packet
|
slave_compressed_protocol
|
replica_compressed_protocol
|
slave_exec_mode
|
replica_exec_mode
|
slave_type_conversions
|
replica_type_conversions
|
slave_sql_verify_checksum
|
replica_sql_verify_checksum
|
slave_parallel_type
|
replica_parallel_type
|
slave_preserve_commit_order
|
replica_preserve_commit_order
|
log_slave_updates
|
log_replica_updates
|
slave_allow_batching
|
replica_allow_batching
|
slave_load_tmpdir
|
replica_load_tmpdir
|
slave_net_timeout
|
replica_net_timeout
|
sql_slave_skip_counter
|
sql_replica_skip_counter
|
slave_skip_errors
|
replica_skip_errors
|
slave_checkpoint_period
|
replica_checkpoint_period
|
slave_checkpoint_group
|
replica_checkpoint_group
|
slave_transaction_retries
|
replica_transaction_retries
|
slave_parallel_workers
|
replica_parallel_workers
|
slave_pending_jobs_size_max
|
replica_pending_jobs_size_max
|
pseudo_slave_mode
|
pseudo_replica_mode
|
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_set_master_auto_position
|
mysql.rds_set_source_auto_position
|
mysql.rds_set_external_master
|
mysql.rds_set_external_source
|
mysql.rds_set_external_master_with_auto_position
|
mysql.rds_set_external_source_with_auto_position
|
mysql.rds_reset_external_master
|
mysql.rds_reset_external_source
|
mysql.rds_next_master_log
|
mysql.rds_next_source_log
|
AUTO_INCREMENT-Werte
In Aurora MySQL Version 3 bewahrt AuroraAUTO_INCREMENTWert für jede Tabelle, wenn jede DB-Instance neu gestartet wird. In Aurora MySQL Version 2 wirdAUTO_INCREMENTDer Wert wurde nach einem Neustart nicht beibehalten.
DieAUTO_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 dieAUTO_INCREMENTvalue 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 unterReplizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation)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 unterSo bewerten Server Replikationsfilterregeln
Transaktionskomprimierung für die Binärprotokollreplikation
Informationen zur Verwendung zur Binärprotokollkomprimierung finden Sie unterBinärprotokoll-Transaktionskomprimierung
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.
