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 bei der Arbeit Amazon RDS for MySQL sind wie folgt.
Themen
- Reserviertes Wort InnoDB
- Vollständiges Storage-Verhalten für Amazon RDS for MySQL
- Inkonsistente Größe des InnoDB-Buffer-Pools
- Index-Merge-Optimierung zeigt falsche Ergebnisse an
- MySQL-Parameterausnahmen für Amazon RDS-DB-Instances
- MySQL-Dateigrößenlimits in Amazon RDS
- MySQL Keyring-Plugin wird nicht unterstützt
- Benutzerdefinierte Ports
- Einschränkungen bei gespeicherten MySQL-Prozeduren
- GTID-basierte Replikation mit einer externen Quell-Instance
- MySQL-Standardauthentifizierungs-Plugin
- Überschreiben von innodb_buffer_pool_size
- Upgrade von MySQL 5.7 auf MySQL 8.4
- InnoDB-Seitenkomprimierung
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:
-
Ändern Sie die DB-Instance, um die automatische Speicherung zu aktivieren.
Weitere Informationen zum Autoscaling von Storage finden Sie unter Automatische Kapazitätsverwaltung mit automatischer Amazon RDS-Speicherskalierung.
-
Ändern Sie die DB-Instance, um ihre Speicherkapazität zu erhöhen.
Weitere Informationen zur Erhöhung der Speicherkapazität finden Sie unter Steigern der DB-Instance-Speicherkapazität.
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
Einzelheiten zu diesem MySQL 5.7-Bug finden Sie unter https://bugs.mysql.com/bug.php? id=79379
Index-Merge-Optimierung zeigt falsche Ergebnisse an
Abfragen, die die Optimierung der Indexzusammenführung verwenden, können aufgrund eines Fehlers im MySQL-Abfrageoptimierer, der in MySQL 5.5.37 eingeführt wurde, falsche Ergebnisse zurückgeben. 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
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. Aufgrund des Fehlers sind die zusammengeführten Ergebnisse jedoch 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 aufindex_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 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
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 Vergleiche unterscheiden nicht zwischen Groß- und Kleinschreibung) wird für RDS for MySQL Version 5.7, Version 8.0.28 und höhere Versionen 8.0 und 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. 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 oder 8.4 verknüpft ist, können Sie den lower_case_table_names
Parameter 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 MySQL-Versionen 8.0 und höhere DB-Instances beträgt die maximale Dateigröße 16 TiB. Bei der Verwendung von file-per-table Tablespaces begrenzt die maximale Dateigröße die Größe einer InnoDB-Tabelle auf 16 TiB. file-per-tableInnoDB-Tablespaces (mit Tabellen in jeweils einem eigenen Tablespace) sind standardmäßig für MySQL-DB-Instances festgelegt. Weitere Informationen finden Sie unter InnoDB-Grenzwerte
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 File-per-table Tablespaces
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
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 Datenwörterbuch-Tablespace ist spezifisch für MySQL 8.0 und höhere Versionen.
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;
Um die Größe von InnoDB-Benutzertabellen außerhalb des InnoDB-System-Tablespace zu bestimmen (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';
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 Parametergruppen für Amazon RDS.
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 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 die auf globalen Transaktions-Identifikatoren (GTIDs) basierende Replikation von einer externen MySQL-Instance in eine Amazon RDS for MySQL MySQL-DB-Instance, für die während der Konfiguration GTID_PURGED gesetzt werden muss. Diese Funktionalität wird jedoch nur von RDS for MySQL 8.0.37 und höheren Versionen unterstützt.
MySQL-Standardauthentifizierungs-Plugin
RDS für MySQL Version 8.0.34 und höhere Versionen 8.0 verwenden das mysql_native_password
Plugin. Sie können die default_authentication_plugin
-Einstellung nicht ändern.
RDS für MySQL Version 8.4 und höhere Versionen verwenden das caching_sha2_password
Plugin als Standard-Authentifizierungs-Plugin. Sie können das Standard-Authentifizierungs-Plugin für MySQL 8.4 ändern. Das mysql_native_password
Plugin funktioniert immer noch 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 Sie den Wert des authentication_policy
Parameters. Weitere Informationen finden Sie unter Standard- und benutzerdefinierte Parametergruppen.
Ü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
Upgrade von MySQL 5.7 auf MySQL 8.4
Sie können nicht direkt von MySQL 5.7 auf MySQL 8.4 aktualisieren. 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 Hauptversions-Upgrades für RDS for MySQL.
InnoDB-Seitenkomprimierung
Die InnoDB-Seitenkomprimierung funktioniert nicht mit Amazon RDS-DB-Instances, die eine Dateisystem-Blockgröße von 16 KB haben, da die Dateisystem-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-Verbrauch bei Seitenlöschungen senkt.