Bekannte Probleme und Einschränkungen für Amazon RDS für MySQL - Amazon Relational Database Service

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.

Bekannte Probleme und Einschränkungen für Amazon RDS für MySQL

Bekannte Probleme und Einschränkungen bei der Arbeit Amazon RDS für MySQL sind wie folgt.

Reserviertes Wort InnoDB

InnoDB ist ein reserviertes Wort für RDS für MySQL. Sie können diesen Namen für eine MySQL-Datenbank nicht verwenden.

Vollständiges Storage-Verhalten für Amazon RDS für MySQL

Wenn der Speicher für eine MySQL-DB-Instance voll ist, kann es zu Inkonsistenzen bei Metadaten, Diskatorkonsistenzen und verwaisten Tabellen kommen. Um diese Probleme zu vermeiden, stoppt Amazon RDS automatisch eine DB-Instance, die den storage-full Status erreicht.

Eine MySQL-DB-Instance erreicht den storage-full Status in den folgenden Fällen:

  • Die DB-Instance verfügt über weniger als 20 000 MiB Speicher, und der verfügbare Speicher erreicht 200 MiB oder weniger.

  • Die DB-Instance verfügt über mehr als 102.400 MiB Speicher, und der verfügbare Speicher erreicht 1024 MiB oder weniger.

  • Die DB-Instance verfügt über zwischen 20 000 MiB und 102.400 MiB Speicher und verfügt über weniger als 1% des verfügbaren Speichers.

Nachdem eine DB-Instance automatisch Amazon RDS gestoppt wurde, weil sie den storage-full Status erreicht hat, können Sie sie immer noch ändern. Um die DB-Instance neu zu starten, führen Sie mindestens einen der folgenden Schritte aus:

Nachdem Sie eine dieser Änderungen vorgenommen haben, wird die DB-Instance automatisch neu gestartet. Informationen zum Ändern einer DB-Instance finden Sie unter Ändern einer Amazon-RDS-DB-Instance.

Inkonsistente Größe des InnoDB-Buffer-Pools

Für MySQL 5.7 gibt es aktuell einen Bug beim Verwalten der Größe des InnoDB-Buffer-Pools. MySQL 5.7 könnte den Wert des Parameters innodb_buffer_pool_size an einen großen Wert anpassen, was dazu führen kann, dass der InnoDB-Buffer-Pool zu groß wird und dadurch zu viel Arbeitsspeicher verbraucht. Dieser Effekt kann dazu führen, dass die Ausführung der MySQL-Datenbank-Engine beendet wird oder die Engine nicht gestartet werden kann. Dieses Problem ist häufiger bei DB-Instance-Klassen vorhanden, die weniger Arbeitsspeicher zur Verfügung haben.

Setzen Sie den Wert des Parameters innodb_buffer_pool_size auf ein Vielfaches des Produkts der Parameterwerte innodb_buffer_pool_instances und innodb_buffer_pool_chunk_size, um das Problem zu beheben. Sie könnten beispielsweise den Parameterwert innodb_buffer_pool_size auf das achtfache des Produkts der Parameterwerte innodb_buffer_pool_instances und innodb_buffer_pool_chunk_size setzen, wie im folgenden Beispiel gezeigt.

innodb_buffer_pool_chunk_size = 536870912 innodb_buffer_pool_instances = 4 innodb_buffer_pool_size = (536870912 * 4) * 8 = 17179869184

Weitere Details zu diesem Bug in MySQL 5.7 finden Sie unter https://bugs.mysql.com/bug.php?id=79379 in der MySQL-Dokumentation.

Index-Merge-Optimierung zeigt falsche Ergebnisse an

Abfragen über die Index-Merge-Optimierung geben aufgrund eines Fehlers im MySQL-Abfrageoptimierer, der in MySQL 5.5.37 eingeführt wurde, möglicherweise falsche Ergebnisse zurück. Wenn Sie eine Abfrage für eine Tabelle mit mehreren Indizes ausführen, scannt der Optimierer die Zeilenbereiche anhand der Indizes, führt die Ergebnisse jedoch nicht korrekt zusammen. Weitere Informationen zum Bug im Abfragenoptimierer finden Sie unter http://bugs.mysql.com/bug.php?id=72745 und http://bugs.mysql.com/bug.php?id=68194 in der MySQL-Bug-Datenbank.

Denken Sie beispielsweise an eine Abfrage für eine Tabelle mit zwei Indizes, wobei die Suchmuster auf die indizierten Spalten verweisen.

SELECT * FROM table1 WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';

In diesem Fall durchsucht die Suchmaschine beide Indizes. Jedoch sind die zusammengeführten Ergebnisse aufgrund des Programmfehlers falsch.

Um dieses Problem zu beheben, können Sie eine der folgenden Aktionen ausführen:

  • Stellen Sie den Parameter optimizer_switch in Ihrer DB-Parametergruppe für Ihre MySQL-DB-Instance auf index_merge=off ein. Weitere Informationen über das Einstellen von Parametern in DB-Parametergruppen finden Sie unter Parametergruppen für Amazon RDS.

  • Führen Sie für Ihre MySQL-DB-Instance ein Upgrade auf MySQL Version 5.7 oder 8.0 durch. Weitere Informationen finden Sie unter Upgrades der DB-Engine von RDS für MySQL.

  • Wenn Sie Ihre Instance nicht upgraden oder den Parameter optimizer_switch nicht ändern können, können Sie alternativ einen Index für die Abfrage explizit bestimmen, beispielsweise so:

    SELECT * FROM table1 USE INDEX covering_index WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';

Weitere Informationen finden Sie unter Index-Merge-Optimierung in der MySQL-Dokumentation.

MySQL-Parameterausnahmen für Amazon-RDS-DB-Instances

Einige MySQL-Parameter erfordern besondere Beachtung bei der Verwendung in einer Amazon-RDS-DB-Instance.

lower_case_table_names

Da Amazon RDS ein Dateisystem mit Berücksichtigung von Groß- und Kleinschreibung verwendet, wird die Festlegung des Werts 2 für den Serverparameter lower_case_table_names (Namen werden wie angegeben gespeichert, aber in Kleinbuchstaben verglichen) nicht unterstützt. Nachfolgend sind die unterstützten Werte für Amazon RDS für MySQL DB-Instances aufgeführt:

  • 0 (Namen werden wie angegeben gespeichert und bei Vergleichen wird die Groß-/Kleinschreibung berücksichtigt) wird für alle RDS-für-MySQL-Versionen unterstützt.

  • 1 (Namen werden in Kleinbuchstaben gespeichert und bei Vergleichen wird die Groß- und Kleinschreibung nicht beachtet) wird für RDS für MySQL Version 5.7, Version 8.0.28 und höhere 8.0-Versionen sowie Version 8.4 unterstützt.

Legen Sie den Parameter lower_case_table_names in einer benutzerdefinierten DB-Parametergruppe fest, bevor Sie eine DB-Instance erstellen. Stellen Sie dann die benutzerdefinierte DB-Parametergruppe ein, wenn Sie die DB-Instance erstellen.

Wenn eine Parametergruppe mit einer MySQL-DB-Instance mit einer niedrigeren Version als 8.0 verknüpft ist, empfehlen wir, die Parameter lower_case_table_names in der Parametergruppe nicht zu ändern. Änderungen können zu Unbeständigkeiten bei Backups für die zeitpunktbezogene Wiederherstellung und Lesereplikat-DB-Instances führen.

Wenn eine Parametergruppe mit einer DB-Instance von MySQL 8.0 oder 8.4 verknüpft ist, können Sie den Parameter lower_case_table_names in der Parametergruppe nicht ändern.

Lesereplikate sollten immer den selben lower_case_table_names-Parameterwert wie die Quell-DB-Instance verwenden.

long_query_time

Sie können den Parameter long_query_time auf einen Fließkommawert einstellen, damit Sie langsame Abfragen im MySQL-Slow-Query-Protokoll in Mikrosekunden-Auflösung protokollieren können. Sie können einen Wert von z. B. 0,1 Sekunden einstellen (100 Millisekunden), um das Debuggen bei langsamen Transaktionen, die weniger als eine Sekunde dauern, zu erleichtern.

MySQL-Dateigrößenlimits in Amazon RDS

Für DB-Instances der MySQL-Versionen 8.0 und höher beträgt die maximale Dateigröße 16 TiB. Bei der Verwendung der Datei-pro-Tabelle-Tablespaces begrenzt die maximale Dateigröße die Größe einer InnoDB-Tabelle auf 16 TiB. Die Option "innodb_file_per_table", bei der für jede Tabelle ein eigener Tabellenraum angelegt wird, ist die Standardeinstellung für MySQL-DB-Instances. Weitere Informationen finden Sie unter Limits für InnoDB in der MySQL-Dokumentation.

Anmerkung

Einige existierende DB-Instances haben eine Untergrenze. Beispielsweise haben MySQL-DB-Instances, die vor April 2014 erstellt wurden, ein Datei- und Tabellenlimit von 2 TB. Dieses Dateilimit von 2 TB gilt auch für DB-Instances oder Lesereplikate, die aus DB-Snapshots erstellt wurden, die vor April 2014 gemacht wurden, unabhängig davon wann die DB-Instance erstellt wurde.

Die Option der InnoDB-Tabellenräumen (innodb_file_per_table) bietet abhängig von der Anwendung sowohl Vor- als auch Nachteile. Um den besten Ansatz für Ihre Anwendung zu bestimmen, lesen Sie File-per-table tablespaces in der MySQL-Dokumentation.

Es wird nicht empfohlen, die Tabellen bis zur maximal möglichen Größe anwachsen zu lassen. Generell hat es sich bewährt, Daten in kleinere Tabellen zu partitionieren, wodurch sich die Leistung und die Wiederherstellungszeiten verbessern.

Eine Möglichkeit, mit der Sie eine große Tabelle in kleinere Tabellen aufteilen können, ist die Partitionierung. Die Partitionierung verteilt Teile Ihrer großen Tabelle in separate Dateien auf der Basis von Regeln, die Sie angeben. Wenn Sie beispielsweise Transaktionen nach Datum speichern, können Sie Partitionierungsregeln erstellen, mit denen ältere Transaktionen in separate Dateien partitioniert werden. Anschließend können Sie regelmäßig die historischen Transaktionsdaten archivieren, die für Ihre Anwendung nicht ständig verfügbar sein müssen. Weitere Informationen finden Sie unter Partitionierung in der MySQL-Dokumentation.

Da es keine einzelne Systemtabelle oder Ansicht gibt, in der die Größe aller Tabellen und des Tabellenraums des InnoDB-Systems angegeben ist, müssen Sie mehrere Tabellen abfragen, um die Größe der Tabellenräume zu ermitteln.

So ermitteln Sie die Größe des Tabellenraums des InnoDB-Systems und des Tabellenraums des Datenwörterbuchs
  • Verwenden Sie den folgenden SQL-Befehl, um zu bestimmen, ob einer Ihrer Tabellenräume zu groß ist und eventuell partitioniert werden sollte.

    Anmerkung

    Der Tabellenraum des Datenwörterbuchs ist für MySQL 8.0 und höheren Versionen spezifisch.

    select FILE_NAME,TABLESPACE_NAME, ROUND(((TOTAL_EXTENTS*EXTENT_SIZE) /1024/1024/1024), 2) as "File Size (GB)" from information_schema.FILES where tablespace_name in ('mysql','innodb_system');
So ermitteln Sie die Größe von InnoDB-Benutzertabellen außerhalb des Tabellenraums des InnoDB-Systems (für MySQL 5.7-Versionen)
  • Verwenden Sie den folgenden SQL-Befehl, um zu bestimmen, ob eine Ihrer Tabellen zu groß ist und evtl. partitioniert werden sollte.

    SELECT SPACE,NAME,ROUND((ALLOCATED_SIZE/1024/1024/1024), 2) as "Tablespace Size (GB)" FROM information_schema.INNODB_SYS_TABLESPACES ORDER BY 3 DESC;
So ermitteln Sie die Größe von InnoDB-Benutzertabellen außerhalb des Tabellenraums des InnoDB-Systems (für MySQL 8.0 und höhere Versionen)
  • Verwenden Sie den folgenden SQL-Befehl, um zu bestimmen, ob eine Ihrer Tabellen zu groß ist und evtl. partitioniert werden sollte.

    SELECT SPACE,NAME,ROUND((ALLOCATED_SIZE/1024/1024/1024), 2) as "Tablespace Size (GB)" FROM information_schema.INNODB_TABLESPACES ORDER BY 3 DESC;
So ermitteln Sie die Größe von Nicht-InnoDB-Benutzertabellen
  • Verwenden Sie den folgenden SQL-Befehl, um zu bestimmen, ob eine Ihrer Nicht-InnoDB-Benutzertabellen zu groß ist.

    SELECT TABLE_SCHEMA, TABLE_NAME, round(((DATA_LENGTH + INDEX_LENGTH+DATA_FREE) / 1024 / 1024/ 1024), 2) As "Approximate size (GB)" FROM information_schema.TABLES WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema') and ENGINE<>'InnoDB';
So aktivieren Sie InnoDB-Datei-pro-Tabelle-Tabellenräume
  • Setzen Sie den Parameter innodb_file_per_table in der Parametergruppe für die DB-Instance auf 1.

So deaktivieren Sie InnoDB-Datei-pro-Tabelle-Tabellenräume
  • Setzen Sie den Parameter innodb_file_per_table in der Parametergruppe für die DB-Instance auf 0.

Weitere Informationen über das Updaten von Parametergruppen finden Sie unter Parametergruppen für Amazon RDS.

Wenn Sie InnoDB-Datei-pro-Tabelle-Tabellenräume aktiviert oder deaktiviert haben, können Sie einen ALTER TABLE-Befehl ausführen, um eine Tabelle aus dem globalen Tabellenraum in ihren eigenen Tabellenraum zu verschieben, oder umgekehrt, ihren eigenen Tabellenraum in den globalen Tabellenraum, wie in folgenden Beispiel gezeigt wird:

ALTER TABLE table_name TABLESPACE=innodb_file_per_table;

MySQL Keyring-Plugin wird nicht unterstützt

Derzeit unterstützt Amazon RDS für MySQL das MySQL-Amazon-Web-Services-Keyring-Plugin keyring_aws nicht.

Benutzerdefinierte Ports

Amazon RDS blockiert Verbindungen zum benutzerdefinierten Port 33060 für die MySQL-Engine. Wählen Sie einen anderen Port für Ihre MySQL-Engine.

Einschränkungen bei gespeicherten MySQL-Prozeduren

Die gespeicherten Prozeduren mysql.rds_kill und mysql.rds_kill_query können Sitzungen oder Abfragen von MySQL-Benutzern mit Benutzernamen, die länger als 16 Zeichen sind, in den folgenden Versionen von RDS für MySQL nicht beenden:

  • 8.0.32 und niedrigere 8-Versionen

  • 5.7.41 und niedrigere 5.7-Versionen

GTID-basierte Replikation mit einer externen Quell-Instance

Amazon RDS unterstützt eine auf globalen Transaktionskennungen (GTIDs) basierende Replikation von einer externen MySQL-Instance zu einer DB-Instance von Amazon RDS für MySQL, die die Einstellung von GTID_PURGED während der Konfiguration erfordert. Diese Funktion wird jedoch nur in RDS für MySQL ab Version 8.0.37 unterstützt.

Standardauthentifizierungs-Plugin für MySQL

RDS für MySQL 8.0.34 und höhere 8.0-Versionen verwenden das Plugin mysql_native_password. Sie können die default_authentication_plugin-Einstellung nicht ändern.

RDS für MySQL 8.4 und höhere Versionen verwenden das Plugin caching_sha2_password als Standard-Authentifizierungs-Plugin. Sie können das Standard-Authentifizierungs-Plugin für MySQL 8.4 ändern. Das Plugin mysql_native_password funktioniert weiterhin mit MySQL 8.4, aber die Unterstützung dieses Plugins endet mit MySQL 8.4. Um das Standard-Authentifizierungs-Plugin zu ändern, erstellen Sie eine benutzerdefinierte Parametergruppe und ändern den Wert des Parameters authentication_policy. Weitere Informationen finden Sie unter Standard- und benutzerdefinierte Parametergruppen.

Überschreiben von innodb_buffer_pool_size

Bei kleinen oder Mikro-DB-Instance-Klassen kann der Standardwert für den Parameter innodb_buffer_pool_size von dem Wert abweichen, der durch Ausführen des folgenden Befehls zurückgegeben wird:

mysql> SELECT @@innodb_buffer_pool_size;

Dieser Unterschied kann auftreten, wenn Amazon RDS im Rahmen der Verwaltung der DB-Instance-Klassen den Standardwert überschreiben muss. Bei Bedarf können Sie den Standardwert überschreiben und ihn auf einen Wert festlegen, den die DB-Instance-Klasse unterstützt. Um einen gültigen Wert zu ermitteln, addieren Sie die Speicherbelegung und den gesamten auf der DB-Instance verfügbaren Speicher. Weitere Informationen finden Sie unter Amazon-RDS-Instance-Typen.

Wenn die DB-Instance nur über 4 GB Arbeitsspeicher verfügt, können Sie den Parameter innodb_buffer_pool_size nicht auf 8 GB festlegen. Sie können ihn jedoch möglicherweise auf 3 GB festlegen, je nachdem, wie viel Speicherplatz Sie für andere Parameter zugewiesen haben.

Wenn der von Ihnen eingegebene Wert zu groß ist, senkt Amazon RDS den Wert auf die folgenden Grenzwerte:

  • Micro-DB-Instance-Klassen: 256 MB

  • db.t4g.micro-DB-Instance-Klassen: 128 MB

Upgrade von MySQL 5.7 auf MySQL 8.4

Sie können nicht direkt ein Upgrade von MySQL 5.7 auf MySQL 8.4 durchführen. Sie müssen zuerst ein Upgrade von MySQL 5.7 auf MySQL 8.0 und dann ein Upgrade von MySQL 8.0 auf MySQL 8.4 durchführen. Weitere Informationen finden Sie unter Hauptversion-Upgrades von RDS für MySQL.

InnoDB-Seitenkomprimierung

Die InnoDB-Seitenkomprimierung funktioniert nicht mit Amazon-RDS-DB-Instances, die eine Dateisystem-Blockgröße von 16 KB haben, da diese Blockgröße kleiner als die InnoDB-Seitengröße sein muss. Ab Februar 2024 haben alle neu erstellten DB-Instances eine Dateisystem-Blockgröße von 16 KB, was den Durchsatz erhöht und den IOPS-Bedarf bei Seitenlöschungen senkt.