Bekannte Probleme und Einschränkungen für Amazon RDS for 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 for MySQL

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

Reserviertes Wort InnoDB

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

Vollständiges Storage-Verhalten für Amazon RDS for 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 führen aufgrund eines Fehlers im MySQL-Abfrageoptimierer, der in MySQL 5.5.37 eingeführt wurde, möglicherweise zu falschen Ergebnissen. 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 werden die zusammengeführten Informationen aufgrund des Programmfehlers unrichtig sein.

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 Arbeiten mit Parametergruppen.

  • 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 Aktualisieren der MySQL DB-Engine.

  • 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 for 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 und Version 8.0.28 sowie höhere 8.0-Versionen 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. Eine Änderung könnte zu Inkonsistenzen bei point-in-time Wiederherstellungs-Backups und Read Replica-DB-Instances führen.

Wenn eine Parametergruppe mit einer MySQL-DB-Instance der Version 8.0 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

Bei MySQL-DB-Instances beschränkt das maximale Speicherlimit die Größe einer Tabelle auf eine maximale Größe von 16 TB, wenn file-per-table InnoDB-Tablespaces verwendet werden. Dieses Limit beschränkt auch den Tabellenraum des Systems auf maximal 16 TB. file-per-table InnoDB-Tablespaces (mit Tabellen in jeweils einem eigenen Tablespace) sind standardmäßig für MySQL-DB-Instances festgelegt.

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 Verwendung von file-per-table InnoDB-Tablespaces hat je nach Ihrer Anwendung Vor- und Nachteile. Informationen zum besten Ansatz für Ihre Anwendung finden Sie unter ile-per-table F-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 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-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';
Um file-per-table InnoDB-Tablespaces zu aktivieren
  • Setzen Sie den Parameter innodb_file_per_table in der Parametergruppe für die DB-Instance auf 1.

Um file-per-table InnoDB-Tablespaces zu deaktivieren
  • 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 Arbeiten mit Parametergruppen.

Wenn Sie file-per-table InnoDB-Tablespaces aktiviert oder deaktiviert haben, können Sie einen ALTER TABLE Befehl ausführen, um eine Tabelle vom globalen Tablespace in ihren eigenen Tablespace oder von ihrem eigenen Tablespace in den globalen Tablespace zu verschieben, wie im folgenden Beispiel gezeigt:

ALTER TABLE table_name ENGINE=InnoDB;

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

MySQL-Standardauthentifizierungs-Plugin

RDS für MySQL Version 8.0.34 und höher verwendet das mysql_native_password Plugin. Sie können die default_authentication_plugin-Einstellung nicht ändern.

Überschreiben von innodb_buffer_pool_size

Bei Mikro- oder kleinen DB-Instance-Klassen kann der Standardwert für den innodb_buffer_pool_size Parameter von dem Wert abweichen, der beim 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 setzen, den Ihre DB-Instance-Klasse unterstützt. Um einen gültigen Wert zu ermitteln, addieren Sie die Speichernutzung und den gesamten auf Ihrer DB-Instance verfügbaren Speicher. Weitere Informationen finden Sie unter Amazon RDS-Instance-Typen.

Wenn Ihre DB-Instance nur 4 GB Arbeitsspeicher hat, können Sie sie nicht innodb_buffer_pool_size auf 8 GB festlegen, aber Sie können sie möglicherweise auf 3 GB setzen, je nachdem, wie viel Speicher 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