Vergleich von Aurora My SQL Version 2 und Aurora My SQL Version 3 - Amazon Aurora
Unterstützung der Atomic Data Definition Language (DDL)Funktionsunterschiede zwischen Aurora My SQL Version 2 und 3Unterstützung für Instance-KlassenGeänderte ParameterStatusvariablen.Inklusive Sprachänderungen für Aurora My SQL Version 3AUTO_ INCREMENT WerteBinäre Protokoll-Replikation

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 My SQL Version 2 und Aurora My SQL Version 3

Im Folgenden erfahren Sie, welche Änderungen Sie beachten sollten, wenn Sie Ihren Aurora My SQL Version 2-Cluster auf Version 3 aktualisieren.

Unterstützung der Atomic Data Definition Language (DDL)

Eine der größten Änderungen von My SQL 5.7 auf 8.0 ist die Einführung des Atomic Data Dictionary. Vor My SQL 8.0 verwendete das My SQL Data Dictionary 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“ wurden, wenn während eines DDL Vorgangs etwas Unerwartetes passierte, wodurch die dateibasierten Metadaten und die Metadaten der Speicher-Engine nicht mehr synchron waren.

Um dies zu beheben, wurde in My SQL 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, ACIDkonforme Methode zur Verwaltung von Datenbank-Metadaten und löst damit das „atomareDDL“ Problem des alten dateibasierten Ansatzes. Weitere Informationen zum Atomic Data Dictionary finden Sie unter Entfernung des dateibasierten Metadatenspeichers und Unterstützung von Atomic Data Definition Statement im My Reference Manual. SQL

Aufgrund dieser Änderung der Architektur müssen Sie beim Upgrade von Aurora My SQL Version 2 auf Version 3 Folgendes beachten:

  • Die dateibasierten Metadaten von Version 2 müssen während des Upgrade-Vorgangs auf Version 3 in die 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 My SQL 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 vorhandenen Datenbankobjektnamen führen könnten.

Um Ihnen zu helfen, diese Inkompatibilitäten vor dem Upgrade der Engine zu identifizieren, SQL führt Aurora My eine Reihe von Upgrade-Kompatibilitätsprüfungen (Vorprüfungen) durch, um festzustellen, ob Ihr Datenbankwörterbuch inkompatible Objekte enthält, bevor das Datenwörterbuch-Upgrade durchgeführt wird. Weitere Informationen zu den Vorabprüfungen finden Sie unter. Vorabprüfungen für das Upgrade der Hauptversion von Aurora My SQL

Funktionsunterschiede zwischen Aurora My SQL Version 2 und 3

Die folgenden Amazon Aurora SQL My-Funktionen werden in Aurora My SQL for My SQL 5.7 unterstützt, aber diese Funktionen werden in Aurora My SQL for My SQL 8.0 nicht unterstützt:

  • Sie können Aurora My SQL Version 3 nicht verwenden für Aurora Serverless v1-Cluster. Aurora Meine SQL Version 3 funktioniert mit Aurora Serverless v2.

  • Der Lab-Modus gilt nicht für Aurora My SQL Version 3. In Aurora My SQL Version 3 gibt es keine Funktionen für den Labormodus. Instant DDL ersetzt die schnelle DDL Online-Funktion, die früher im Labormodus verfügbar war. Ein Beispiel finden Sie unter Sofortige DDL (Aurora MySQL Version 3).

  • Der Abfrage-Cache wurde aus Community My SQL 8.0 und auch aus Aurora My SQL Version 3 entfernt.

  • Aurora My SQL Version 3 ist mit der Community-Funktion My SQL Hash Join kompatibel. Die Aurora-spezifische Implementierung von Hash-Joins in Aurora My SQL Version 2 wird nicht verwendet. Informationen zur Verwendung von Hash-Joins mit Aurora-Parallelabfrage finden Sie unterHash-Join für parallele Abfrage-Cluster aktivierenundAurora Meine SQL Tippsaus. Allgemeine Informationen zur Verwendung von Hash-Joins finden Sie unter Hash-Join-Optimierung im My SQL Reference Manual.

  • Die mysql.lambda_async gespeicherte Prozedur, die in Aurora My SQL Version 2 veraltet war, wurde in Version 3 entfernt. Verwenden Sie für Version 3 die asynchrone Funktionlambda_asyncStattdessen.

  • Der Standardzeichensatz in Aurora My SQL Version 3 istutf8mb4. In Aurora My SQL Version 2 war der Standardzeichensatzlatin1. Informationen zu diesem Zeichensatz finden Sie unter Der utf8mb4-Zeichensatz (UTF4-Byte-8-Unicode-Kodierung) in Mein Referenzhandbuch. SQL

Einige SQL Funktionen von Aurora My sind für bestimmte Kombinationen aus AWS Region und DB-Engine-Version verfügbar. Details hierzu finden Sie unter Unterstützte Funktionen in Amazon Aurora von AWS-Region und Aurora DB-Engine.

Unterstützung für Instance-Klassen

Aurora My SQL Version 3 unterstützt einen anderen Satz von Instance-Klassen als Aurora My SQL 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 Instanzklassen aus Aurora My SQL Version 2 sind für Aurora My SQL Version 3 nicht verfügbar:

  • db.r4

  • db.r3

  • db.t3.small

  • db.t2

Suchen Sie in Ihren Administrationsskripten nach CLI Anweisungen, die Aurora My SQL DB-Instances erstellen. Hardcode-Instanzklassennamen, die für Aurora My SQL Version 3 nicht verfügbar sind. Ändern Sie bei Bedarf die Instanzklassennamen so, dass sie von Aurora My SQL Version 3 unterstützt werden.

Tipp

Verwenden Sie den describe-orderable-db-instance-options AWS CLI Befehl, um die Instance-Klassen zu überprüfen, die Sie für eine bestimmte Kombination aus Aurora My SQL Version und AWS Region verwenden können.

Ausführliche Einzelheiten zu Aurora-Instance-Klassen finden Sie unter Amazon Aurora Aurora-DB-Instance-Klassen.

Parameteränderungen für Aurora My SQL Version 3

Aurora My SQL Version 3 enthält neue Konfigurationsparameter auf Cluster- und Instanzebene. Aurora My SQL Version 3 entfernt auch einige Parameter, die in Aurora My SQL 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 My SQL Version 3 wird der Wert des lower_case_table_names Parameters zum Zeitpunkt der Clustererstellung dauerhaft festgelegt. Wenn Sie für diese Option einen anderen Wert als den Standardwert verwenden, richten Sie vor dem Upgrade Ihre benutzerdefinierte Parametergruppe Aurora My SQL Version 3 ein. Geben Sie dann die Parametergruppe während des Wiederherstellungsvorgangs „Cluster wiederherstellen“ oder „Snapshot wiederherstellen“ an.

Anmerkung

Bei einer globalen Aurora-Datenbank, die auf Aurora My basiertSQL, können Sie kein direktes Upgrade von Aurora My SQL Version 2 auf Version 3 durchführen, wenn der lower_case_table_names Parameter aktiviert ist. Verwenden Sie stattdessen die Snapshot-Wiederherstellungsmethode.

In Aurora My SQL Version 3 gelten die read_only Parameter init_connect und nicht für Benutzer mit dieser CONNECTION_ADMIN Berechtigung. Dies schließt den Aurora-Hauptbenutzer ein. Weitere Informationen finden Sie unter Rollenbasiertes Berechtigungsmodell.

Die vollständige Liste der Aurora My SQL Cluster-Parameter finden Sie unterParameter auf Cluster-Ebene. Die Tabelle deckt alle Parameter von Aurora My SQL Version 2 und 3 ab. Die Tabelle enthält Hinweise, die zeigen, welche Parameter in Aurora My SQL Version 3 neu sind oder aus Aurora My SQL Version 3 entfernt wurden.

Die vollständige Liste der Aurora My SQL Instance-Parameter finden Sie unterParameter auf Instance-Ebene. Die Tabelle deckt alle Parameter von Aurora My SQL Version 2 und 3 ab. Die Tabelle enthält Hinweise, die zeigen, welche Parameter in Aurora My SQL Version 3 neu sind und welche Parameter aus Aurora My SQL Version 3 entfernt wurden. Es enthält auch Hinweise, die zeigen, welche Parameter in früheren Versionen geändert werden konnten, nicht jedoch in Aurora My SQL Version 3.

Weitere Informationen zu geänderten Parameternamen finden Sie unter Inklusive Sprachänderungen für Aurora My SQL Version 3.

Statusvariablen.

Informationen zu Statusvariablen, die nicht für Aurora My geltenSQL, finden Sie unterMeine SQL Statusvariablen, die nicht für Aurora My gelten SQL.

Inklusive Sprachänderungen für Aurora My SQL Version 3

Aurora My SQL Version 3 ist mit Version 8.0.23 aus der My SQL Community Edition kompatibel. Aurora My SQL Version 3 enthält auch Änderungen gegenüber My SQL 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 My SQL Version 3 neue Namen.

In Aurora My SQL Version 3 sind nur die neuen Metriknamen verfügbar. Stellen Sie sicher, dass Sie alle Alarme oder andere Automatisierungen, die auf Metriknamen basieren, aktualisieren, wenn Sie auf Aurora My SQL Version 3 aktualisieren.

Alter Name Neuer Name
ForwardingMasterDMLLatency ForwardingWriterDMLLatency
ForwardingMasterOpenSessions ForwardingWriterOpenSessions
AuroraDMLRejectedMasterFull AuroraDMLRejectedWriterFull
ForwardingMasterDMLThroughput ForwardingWriterDMLThroughput

Die folgenden Statusvariablen haben in Aurora My SQL Version 3 neue Namen.

Aus Kompatibilitätsgründen können Sie beide Namen in der ersten Version von Aurora My SQL Version 3 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 in Aurora My SQL Version 3 neue Namen.

Aus Kompatibilitätsgründen können Sie die Parameterwerte im mysql Client überprüfen, indem Sie einen der beiden Namen in der ersten Version von Aurora My SQL Version 3 verwenden. 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 in Aurora My SQL Version 3 neue Namen.

Aus Kompatibilitätsgründen können Sie beide Namen in der ersten Version von Aurora My SQL Version 3 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 My SQL Version 3 behält Aurora den AUTO_INCREMENT Wert für jede Tabelle bei, wenn jede DB-Instance neu gestartet wird. In Aurora My SQL Version 2 wurde der AUTO_INCREMENT Wert nach einem Neustart nicht beibehalten.

Der 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 dieAUTO_INCREMENTvalue wird basierend auf dem größten Spaltenwert in der Tabelle zum Zeitpunkt der Erstellung des Snapshots auf den Wert initialisiert. Dieses Verhalten unterscheidet sich RDS von My SQL 8.0, wo der AUTO_INCREMENT Wert bei diesen Vorgängen beibehalten wird.

Binäre Protokoll-Replikation

In My SQL 8.0 Community Edition ist die binäre Protokollreplikation standardmäßig aktiviert. In Aurora My SQL Version 3 ist die binäre Protokollreplikation 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äre Protokollreplikation von einer My SQL 5.7-kompatiblen Quelle auf Aurora My Version 3. SQL Das Quellsystem kann ein Aurora My SQL DB-Cluster, eine RDS for My SQL DB-Instance oder eine lokale My SQL Instance sein.

Wie Community My SQL unterstützt Aurora My die Replikation von einer QuelleSQL, 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 My SQL 5.6-kompatiblen System auf Aurora My SQL Version 3 nicht unterstützt. Die Replikation von Aurora My SQL Version 3 auf ein My 5.7- oder My SQL SQL 5.6-kompatibles System wird nicht unterstützt. Einzelheiten zur Verwendung der Binärprotokollreplikation finden Sie unterReplikation zwischen Aurora und My SQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation)aus.

Aurora My SQL Version 3 enthält Verbesserungen der binären Protokollreplikation in Community My SQL 8.0, z. B. gefilterte Replikation. Einzelheiten zu den Verbesserungen von My SQL 8.0 in der Community finden Sie unter So bewerten Server Replikationsfilterregeln im My SQL Reference Manual.

Transaktionskomprimierung für die Binärprotokollreplikation

Informationen zur Verwendung von Binärprotokollkomprimierung finden Sie unter Komprimierung von Binärprotokolltransaktionen im My SQL Reference Manual.

Die folgenden Einschränkungen gelten für die Komprimierung von Binärprotokollen in Aurora My SQL 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 von SQL Binärprotokollen in Aurora My aktiviert ist. Solche Transaktionen werden repliziert, ohne komprimiert zu werden.

  • Wenn Sie einen Connector für Change Data Capture (CDC) verwenden, der My SQL 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. Wir empfehlen Ihnen außerdem, dies zu tun, bevor Sie die Binlog-Komprimierung auf Systemen aktivieren, für die Binlog-Replikation verwendet wird. CDC