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
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_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 Funktionlambda_async
Stattdessen. -
Der Standardzeichensatz in Aurora MySQL Version 3 ist
utf8mb4
aus. In Aurora MySQL Version 2 war der Standardzeichensatzlatin1
aus. Weitere Informationen zu diesem Zeichensatz finden Sie unterDer utf8mb4-Zeichensatz (UTF-8-Unicode-Kodierung mit 4 Bytes)imMySQL-Referenzhandbuchaus.
Einige Aurora MySQL-Funktionen sind für bestimmte Kombinationen von AWS Region und DB-Engine-Version verfügbar. Details hierzu finden Sie unter Unterstützte Funktionen in Amazon Aurora nach AWS-Region und 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.r6g
unddb.x2g
verwenden. -
Für kleinere Instances können Sie die modernen Instance-Klassen wie
db.t3
unddb.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.
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
Verwenden Sie den describe-orderable-db-instance-options
AWS CLI Befehl, um die Instanzklassen zu überprüfen, die Sie für eine bestimmte Kombination aus Aurora MySQL-Version und AWS Region verwenden können.
Ausführliche Einzelheiten zu Aurora-Instance-Klassen finden Sie unter Aurora DB-Instance-Klassen.
Parameteränderungen für Aurora MySQL Version 3
Aurora MySQL Version 3 enthält neue Konfigurationsparameter auf Clusterebene und Instanzebene. 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 STATUS
Befehl wird jetzt bevorzugt stattSHOW SLAVE STATUS
aus.
Die folgenden CloudWatch Amazon-Metriken haben in Aurora MySQL Version 3 neue Namen.
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_INCREMENT
Wert für jede Tabelle, wenn jede DB-Instance neu gestartet wird. In Aurora MySQL Version 2 wirdAUTO_INCREMENT
Der Wert wurde nach einem Neustart nicht beibehalten.
Der AUTO_INCREMENT
Wert bleibt nicht erhalten, 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_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 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
Multithread-Replikation
Mit Aurora MySQL Version 3 unterstützt Aurora MySQL die Multithread-Replikation. Weitere Informationen zur Nutzung finden Sie unter Multithread-Binärprotokollreplikation (Aurora MySQL Version 3).
Anmerkung
Wir empfehlen weiterhin, keine Multithread-Replikation mit Aurora-MySQL-Version 2 zu verwenden.
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.