Vergleich von Aurora-MySQL-Version 2 und Aurora-MySQL-Version 3 - Amazon Aurora

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.

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-OptimierungimMySQL-Referenzhandbuchaus.

  • Diemysql.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 istutf8mb4aus. 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 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 wiedb.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.

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 STATUSBefehl wird jetzt bevorzugt stattSHOW SLAVE STATUSaus.

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_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.

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_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 ReplikationsfilterregelnimMySQL-Referenzhandbuchaus.

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-Transaktionskomprimierungim 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.