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. # Geläufige DBA-Aufgaben für MySQL-DB-Instances Im folgenden Inhalt finden Sie Beschreibungen der Amazon-RDS-spezifische Implementierungen häufiger DBA-Aufgaben für DB-Instances, auf denen die MySQL-Datenbank-Engine ausgeführt wird. Um eine verwaltete Service-Erfahrung zu bieten, ermöglicht Amazon RDS keinen Shell-Zugriff auf DB-Instances. Eingeschränkt wird auch der Zugriff auf bestimmte Systemprozeduren und Tabellen, für die erweiterte Berechtigungen erforderlich sind. Informationen zum Arbeiten mit MySQL-Protokolldateien in Amazon RDS finden Sie unter [ MySQL-Datenbank-Logdateien](USER_LogAccess.Concepts.MySQL.md). ## Grundlegendes zu vordefinierten Benutzern Amazon RDS erstellt automatisch mehrere im vordefinierte Benutzer mit neuen DB-Instances von RDS für MySQL. Vordefinierte Benutzer und ihre Berechtigungen können nicht geändert werden. Sie können Berechtigungen für diese vordefinierten Benutzer nicht löschen, umbenennen oder ändern. Jeder entsprechende Versuch führt zu einem Fehler. + **rdsadmin** – Ein Benutzer, der erstellt wurde, um viele der Verwaltungsaufgaben zu erledigen, die der Administrator mit `superuser`-Berechtigungen für eine eigenständige MySQL-Datenbank ausführt. Dieser Benutzer wird intern von RDS für MySQL für viele Verwaltungsaufgaben verwendet. + **rdsrepladmin** – Ein Benutzer, der intern von Amazon RDS verwendet wird, um Replikationsaktivitäten auf DB-Instances und Clustern von RDS für MySQL zu unterstützen. Weitere Informationen zu anderen häufigen DBA-Aufgaben finden Sie unter den folgenden Themen. **Topics** + [ ## Grundlegendes zu vordefinierten Benutzern ](#Appendix.MySQL.CommonDBATasks.users) + [ # Rollenbasiertes Berechtigungsmodell für RDS für MySQL ](Appendix.MySQL.CommonDBATasks.privilege-model.md) + [ # Dynamische Berechtigungen für RDS für MySQL ](Appendix.MySQL.CommonDBATasks.dynamic-privileges.md) + [ # Beenden einer Sitzung oder Abfrage für RDS für MySQL ](Appendix.MySQL.CommonDBATasks.End.md) + [ # Überspringen des aktuellen Replikationsfehlers für RDS für MySQL ](Appendix.MySQL.CommonDBATasks.SkipError.md) + [ # Arbeiten mit InnoDB-Tabellenräumen zur Verbesserung der Wiederherstellungszeiten nach Abstürzen für RDS für MySQL ](Appendix.MySQL.CommonDBATasks.Tables.md) + [ # Verwalten des globalen Statusverlaufs für RDS für MySQL ](Appendix.MySQL.CommonDBATasks.GoSH.md) + [ # Konfigurieren der Pufferpoolgröße und der Redo-Protokollkapazität in MySQL 8.4 ](Appendix.MySQL.CommonDBATasks.Config.Size.8.4.md) # Rollenbasiertes Berechtigungsmodell für RDS für MySQL Ab RDS für MySQL Version 8.0.36 können Sie die Tabellen in der `mysql`-Datenbank nicht direkt ändern. Insbesondere können Sie keine Datenbankbenutzer erstellen, indem Sie DML-Vorgänge (Data Manipulation Language) in den `grant`-Tabellen durchführen. Stattdessen verwenden Sie MySQL-Kontoverwaltungsanweisungen wie `CREATE USER`, `GRANT` und `REVOKE`, um Benutzern rollenbasierte Berechtigungen zu gewähren. Sie können auch keine anderen Objekte wie gespeicherte Prozeduren in der `mysql`-Datenbank erstellen. Sie können immer noch die `mysql`-Tabellen abfragen. Wenn Sie die Binärprotokollreplikation verwenden, werden Änderungen direkt an `mysql`-Tabellen im Quell-DB-Cluster nicht auf den Zielcluster repliziert. In einigen Fällen verwendet Ihre Anwendung möglicherweise Verknüpfungen, um Benutzer oder andere Objekte zu erstellen, indem Sie sie in die`mysql`-Tabellen Wenn ja, ändern Sie Ihren Anwendungscode, um die entsprechenden Anweisungen wie `CREATE USER` zu verwenden. Um Metadaten für Datenbankbenutzer während der Migration aus einer externen MySQL-Datenbank zu exportieren, können Sie eine der folgenden Methoden verwenden. + Verwenden Sie das Instance-Dump-Dienstprogramm von MySQL Shell mit einem Filter, um Benutzer, Rollen und Erteilungen auszuschließen. Das folgende Beispiel zeigt die zu verwendenden Befehle. Stellen Sie sicher, dass `outputUrl` leer ist. ``` mysqlsh user@host -- util.dumpInstance(outputUrl,{excludeSchemas:['mysql'],users: true}) ``` Weitere Informationen finden Sie unter [Instance-Dump-Dienstprogramm, Schema-Dump-Dienstprogramm und Tabellen-Dump-Dienstprogramm](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html) im MySQL-Referenzhandbuch. + Verwenden Sie das Client-Dienstprogramm `mysqlpump`. Dieses Beispiel umfasst alle Tabellen mit Ausnahme der Tabellen in der `mysql`-Systemdatenbank. Sie enthalten auch `CREATE USER` und `GRANT`-Anweisungen zur Reproduktion aller MySQL-Benutzer in der migrierten Datenbank. ``` mysqlpump --exclude-databases=mysql --users ``` Das Client-Dienstprogramm `mysqlpump` ist in MySQL 8.4 nicht mehr verfügbar. Nutzen Sie stattdessen `mysqldump`. Um die Verwaltung von Berechtigungen für viele Benutzer oder Anwendungen zu vereinfachen, können Sie`CREATE ROLE`-Anweisung zum Erstellen einer Rolle mit einer Reihe von Berechtigungen. Dann können Sie die`GRANT`und`SET ROLE`-Anweisungen und die`current_role`Funktion, um Benutzern oder Anwendungen Rollen zuzuweisen, die aktuelle Rolle zu wechseln und zu überprüfen, welche Rollen in Kraft sind. Weitere Informationen zum rollenbasierten Berechtigungssystem in MySQL 8.0 finden Sie unter [Verwenden von Rollen](https://dev.mysql.com/doc/refman/8.0/en/roles.html) im MySQL-Referenzhandbuch. **Wichtig** Wir empfehlen Ihnen, den Hauptbenutzer nicht direkt in Ihren Anwendungen zu verwenden. Bleiben Sie stattdessen bei der bewährten Methode, einen Datenbankbenutzer zu verwenden, der mit den Mindestberechtigungen erstellt wurde, die für Ihre Anwendung erforderlich sind. Ab Version 8.0.36 enthält RDS für MySQL eine spezielle Rolle, die alle folgenden Berechtigungen besitzt. Der Name der Rolle lautet `rds_superuser_role`. Dem primären Administratorbenutzer für jede DB-Instance wurde diese Rolle bereits gewährt. Die`rds_superuser_role`enthält die folgenden Berechtigungen für alle Datenbankobjekte: + `ALTER` + `APPLICATION_PASSWORD_ADMIN` + `ALTER ROUTINE` + `CREATE` + `CREATE ROLE` + `CREATE ROUTINE` + `CREATE TEMPORARY TABLES` + `CREATE USER` + `CREATE VIEW` + `DELETE` + `DROP` + `DROP ROLE` + `EVENT` + `EXECUTE` + `INDEX` + `INSERT` + `LOCK TABLES` + `PROCESS` + `REFERENCES` + `RELOAD` + `REPLICATION CLIENT` + `REPLICATION SLAVE` + `ROLE_ADMIN` + `SET_USER_ID` + `SELECT` + `SHOW DATABASES` + `SHOW VIEW` + `TRIGGER` + `UPDATE` + `XA_RECOVER_ADMIN` Die Rollendefinition umfasst auch`WITH GRANT OPTION`damit ein Administratorbenutzer diese Rolle anderen Benutzern gewähren kann. Insbesondere muss der Administrator alle Berechtigungen erteilen, die zur Durchführung der Binärprotokollreplikation mit dem MySQL-Cluster als Ziel erforderlich sind. **Tipp** Um die vollständigen Details der Berechtigungen anzuzeigen, verwenden Sie die folgenden Anweisungen. ``` SHOW GRANTS FOR rds_superuser_role@'%'; ``` Wenn Sie Zugriff mithilfe von Rollen in RDS für MySQL Version 8.0.36 und höher gewähren, aktivieren Sie die Rolle auch mithilfe der `SET ROLE role_name`- oder`SET ROLE ALL`-Anweisung. Im folgenden Beispiel wird gezeigt, wie dies geschieht. Ersetzen Sie den entsprechenden Rollennamen für `CUSTOM_ROLE`. ``` # Grant role to user mysql> GRANT CUSTOM_ROLE TO 'user'@'domain-or-ip-address' # Check the current roles for your user. In this case, the CUSTOM_ROLE role has not been activated. # Only the rds_superuser_role is currently in effect. mysql> SELECT CURRENT_ROLE(); +--------------------------+ | CURRENT_ROLE() | +--------------------------+ | `rds_superuser_role`@`%` | +--------------------------+ 1 row in set (0.00 sec) # Activate all roles associated with this user using SET ROLE. # You can activate specific roles or all roles. # In this case, the user only has 2 roles, so we specify ALL. mysql> SET ROLE ALL; Query OK, 0 rows affected (0.00 sec) # Verify role is now active mysql> SELECT CURRENT_ROLE(); +--------------------------------------------------+ | CURRENT_ROLE() | +--------------------------------------------------+ | `CUSTOM_ROLE`@`%`,`rds_superuser_role`@`%` | +--------------------------------------------------+ ``` # Dynamische Berechtigungen für RDS für MySQL Dynamische Berechtigungen sind MySQL-Berechtigungen, die Sie mithilfe der `GRANT`-Anweisung explizit gewähren können. Abhängig von Ihrer Version von RDS für MySQL können Sie mit RDS nur bestimmte dynamische Berechtigungen gewähren. RDS verbietet einige dieser Berechtigungen, da sie die spezifischen Datenbankvorgänge wie Replikation und Sicherung beeinträchtigen können. Die folgende Tabelle zeigt, welche dieser Berechtigungen Sie für verschiedene MySQL-Versionen gewähren können. Wenn Sie von einer MySQL-Version unter 8.0.36 auf Version 8.0.36 oder höher aktualisieren, müssen Sie möglicherweise Ihren Anwendungscode aktualisieren, wenn die Gewährung einer bestimmten Berechtigung nicht mehr zulässig ist. | Recht | MySQL 8.0.35 und niedriger | MySQL 8.0.36 und höhere Unterversionen | MySQL 8.4.3 und höher | | --- | --- | --- | --- | | [ALLOW\$1NONEXISTENT\$1DEFINER](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_allow-nonexistent-definer) | Nicht verfügbar | Nicht verfügbar | Unzulässige | | [APPLICATION\$1PASSWORD\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_application-password-admin) | Zulässig | Zulässig | Zulässig | | [AUDIT\$1ABORT\$1EXEMPT](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_audit-abort-exempt) | Zulässig | Unzulässige | Unzulässige | | [AUDIT\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_audit-admin) | Unzulässige | Unzulässige | Unzulässige | | [AUTHENTICATION\$1POLICY\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_authentication-policy-admin) | Zulässig | Unzulässige | Unzulässige | | [BACKUP\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_backup-admin) | Zulässig | Unzulässige | Unzulässige | | [BINLOG\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_binlog-admin) | Zulässig | Unzulässige | Unzulässige | | [BINLOG\$1ENCRYPTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_binlog-encryption-admin) | Unzulässige | Unzulässige | Unzulässige | | [CLONE\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_clone-admin) | Unzulässige | Unzulässige | Unzulässige | | [CONNECTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_connection-admin) | Zulässig | Unzulässige | Unzulässige | | [ENCRYPTION\$1KEY\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_encryption-key-admin) | Unzulässige | Unzulässige | Unzulässige | | [FIREWALL\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_firewall-admin) | Unzulässige | Unzulässige | Unzulässige | | [FIREWALL\$1EXEMPT](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_firewall-exempt) | Zulässig | Unzulässige | Unzulässige | | [FIREWALL\$1USER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_firewall-user) | Unzulässige | Unzulässige | Unzulässige | | [FLUSH\$1OPTIMIZER\$1COSTS](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_flush-optimizer-costs) | Zulässig | Zulässig | Zulässig | | [FLUSH\$1PRIVILEGES](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_flush-privileges) | Nicht verfügbar | Nicht verfügbar | Zulässig | | [FLUSH\$1STATUS](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_flush-status) | Zulässig | Zulässig | Zulässig | | [FLUSH\$1TABLES](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_flush-tables) | Zulässig | Zulässig | Zulässig | | [FLUSH\$1USER\$1RESOURCES](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_flush-user-resources) | Zulässig | Zulässig | Zulässig | | [GROUP\$1REPLICATION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_group-replication-admin) | Unzulässige | Unzulässige | Unzulässige | | [GROUP\$1REPLICATION\$1STREAM](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_group-replication-stream) | Unzulässige | Unzulässige | Unzulässige | | [INNODB\$1REDO\$1LOG\$1ARCHIVE](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_innodb-redo-log-archive) | Unzulässige | Unzulässige | Unzulässige | | [INNODB\$1REDO\$1LOG\$1ENABLE](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_innodb-redo-log-enable) | Unzulässige | Unzulässige | Unzulässige | | [MASKING\$1DICTIONARIES\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_masking-dictionaries-admin) | Unzulässige | Unzulässige | Unzulässige | | [NDB\$1STORED\$1USER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_ndb-stored-user) | Unzulässige | Unzulässige | Unzulässige | | [OPTIMIZE\$1LOCAL\$1TABLE](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_optimize-local-table) | Nicht verfügbar | Nicht verfügbar | Unzulässige | | [PASSWORDLESS\$1USER\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_passwordless-user-admin) | Unzulässige | Unzulässige | Unzulässige | | [PERSIST\$1RO\$1VARIABLES\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_persist-ro-variables-admin) | Unzulässige | Unzulässige | Unzulässige | | [REPLICATION\$1APPLIER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_replication-applier) | Zulässig | Unzulässige | Unzulässige | | [REPLICATION\$1SLAVE\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_replication-slave-admin) | Unzulässige | Unzulässige | Unzulässige | | [RESOURCE\$1GROUP\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_resource-group-admin) | Zulässig | Unzulässige | Unzulässige | | [RESOURCE\$1GROUP\$1USER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_resource-group-user) | Zulässig | Unzulässige | Unzulässige | | [ROLE\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_role-admin) | Zulässig | Zulässig | Zulässig | | [SENSITIVE\$1VARIABLES\$1OBSERVER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_sensitive-variables-observer) | Zulässig | Zulässig | Zulässig | | [SERVICE\$1CONNECTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_service-connection-admin) | Zulässig | Unzulässige | Unzulässige | | [SESSION\$1VARIABLES\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_session-variables-admin) | Zulässig | Zulässig | Zulässig | | [SET\$1ANY\$1DEFINER](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_set-any-definer) | Nicht verfügbar | Nicht verfügbar | Zulässig | | [SET\$1USER\$1ID](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_set-user-id) | Zulässig | Zulässig | Nicht verfügbar | | [SHOW\$1ROUTINE](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_show-routine) | Zulässig | Zulässig | Zulässig | | [SKIP\$1QUERY\$1REWRITE](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_skip-query-rewrite) | Unzulässige | Unzulässige | Unzulässige | | [SYSTEM\$1USER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_system-user) | Unzulässige | Unzulässige | Unzulässige | | [SYSTEM\$1VARIABLES\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_system-variables-admin) | Unzulässige | Unzulässige | Unzulässige | | [TABLE\$1ENCRYPTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_table-encryption-admin) | Unzulässige | Unzulässige | Unzulässige | | [TELEMETRY\$1LOG\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_telemetry-log-admin) | Zulässig | Unzulässige | Unzulässige | | [TP\$1CONNECTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_tp-connection-admin) | Unzulässige | Unzulässige | Unzulässige | | [TRANSACTION\$1GTID\$1TAG](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_transaction-gtid-tag) | Nicht verfügbar | Nicht verfügbar | Unzulässige | | [VERSION\$1TOKEN\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_version-token-admin) | Unzulässige | Unzulässige | Unzulässige | | [XA\$1RECOVER\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_xa-recover-admin) | Zulässig | Zulässig | Zulässig | # Beenden einer Sitzung oder Abfrage für RDS für MySQL Sie können Benutzersitzungen oder Abfragen in DB-Instances mit den Befehlen `rds_kill` und `rds_kill_query` beenden. Stellen Sie zunächst eine Verbindung mit Ihrer MySQL-DB-Instance her und geben Sie anschließend den entsprechenden Befehl aus, wie im Folgenden gezeigt. Weitere Informationen finden Sie unter [Herstellen einer Verbindung mit Ihrer MySQL-DB-Instance](USER_ConnectToInstance.md). ``` CALL mysql.rds_kill(thread-ID) CALL mysql.rds_kill_query(thread-ID) ``` Um beispielsweise die Sitzung zu beenden, die auf Thread 99 ausgeführt wird, würden Sie Folgendes eingeben: ``` CALL mysql.rds_kill(99); ``` Um die Abfrage zu beenden, die auf Thread 99 ausgeführt wird, würden Sie Folgendes eingeben: ``` CALL mysql.rds_kill_query(99); ``` # Überspringen des aktuellen Replikationsfehlers für RDS für MySQL Amazon RDS stellt einen Mechanismus bereit, mit dem Sie einen Fehler für Ihre Lesereplikate überspringen können, wenn der Fehler dazu führt, dass Ihr Lesereplikat aufhört zu reagieren und der Fehler keine Auswirkungen auf die Integrität Ihrer Daten hat. **Anmerkung** Sie sollten zunächst überprüfen, ob der Fehler sicher übersprungen werden kann. Stellen Sie in einem MySQL-Hilfsprogramm eine Verbindung mit dem Lesereplikat her und führen Sie den folgenden MySQL-Befehl aus: ``` SHOW REPLICA STATUS\G ``` Informationen zu den zurückgegebenen Werten finden Sie in [der MySQL-Dokumentation](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html). Frühere Versionen von MySQL verwenden `SHOW SLAVE STATUS` anstelle von `SHOW REPLICA STATUS`. Wenn Sie vor 8.0.23 eine MySQL-Version verwenden, verwenden Si `SHOW SLAVE STATUS`. Sie können einen Fehler in Ihrem Lesereplikat wie folgt überspringen. **Topics** + [ ## Aufrufen der Prozedur mysql.rds\$1skip\$1repl\$1error ](#Appendix.MySQL.CommonDBATasks.SkipError.procedure) + [ ## Festlegen des Parameters slave\$1skip\$1error ](#Appendix.MySQL.CommonDBATasks.SkipError.parameter) ## Aufrufen der Prozedur mysql.rds\$1skip\$1repl\$1error Amazon RDS bietet eine gespeicherte Prozedur, die Sie aufrufen können, um einen Fehler bei Ihren Read-Replikaten zu überspringen. Stellen Sie zunächst eine Verbindung mit Ihrer MySQL-DB-Instance her und geben Sie anschließend den entsprechenden Befehl aus, wie im Folgenden gezeigt. Weitere Informationen finden Sie unter [Herstellen einer Verbindung mit Ihrer MySQL-DB-Instance](USER_ConnectToInstance.md). Um den Fehler zu überspringen, können Sie den folgenden Befehl ausgeben: ``` CALL mysql.rds_skip_repl_error; ``` Dieser Befehl hat keine Auswirkungen, wenn Sie ihn auf der Quell-DB-Instance oder einem Lesereplikat ausführen, für den kein Replikationsfehler aufgetreten ist. Weitere Informationen wie beispielsweise zu den Versionen von MySQL, die `mysql.rds_skip_repl_error` unterstützen, finden Sie unter [mysql.rds\$1skip\$1repl\$1error](mysql-stored-proc-replicating.md#mysql_rds_skip_repl_error). **Wichtig** Wenn Sie versuchen, `mysql.rds_skip_repl_error` aufzurufen und der Fehler `ERROR 1305 (42000): PROCEDURE mysql.rds_skip_repl_error does not exist` angezeigt wird, müssen Sie Ihre MySQL-DB-Instance auf die neueste kleinere Version oder eine der kleineren mindestens erforderlichen Versionen aktualisieren, die in [mysql.rds\$1skip\$1repl\$1error](mysql-stored-proc-replicating.md#mysql_rds_skip_repl_error) aufgelistet werden. ## Festlegen des Parameters slave\$1skip\$1error Um einen oder mehrere Fehler zu überspringen, können Sie die `slave_skip_errors` statischer Parameter für das Lesereplikat setzen. Sie können diesen Parameter so einstellen, dass ein oder mehrere spezifische Replikationsfehlercodes übersprungen werden. Derzeit können Sie diesen Parameter nur für RDS für MySQL 5.7 DB-Instances festlegen. Nachdem Sie die Einstellung für diesen Parameter geändert haben, starten Sie Ihre DB-Instance neu, damit die neue Einstellung wirksam wird. Weitere Informationen zur Funktionsweise dieser Parameter finden Sie in der [MySQL-Dokumentation](https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_slave_skip_errors). Wir empfehlen, diesen Parameter in einer separaten DB-Parametergruppe einzustellen. Sie können diese DB-Parametergruppe nur den Lese-Replikaten zuordnen, die Fehler überspringen müssen. Nach dieser Best Practice werden die potenziellen Auswirkungen auf andere DB-Instances und Lese-Replikate reduziert. **Wichtig** Das Festlegen eines nicht standardmäßigen Werts für diesen Parameter kann zu Inkonsistenz der Replikation führen. Stellen Sie diesen Parameter nur auf einen nicht standardmäßigen Wert ein, wenn Sie andere Optionen zur Behebung des Problems ausgeschöpft haben und Sie sich der möglichen Auswirkungen auf die Daten Ihres Read Replica sicher sind. # Arbeiten mit InnoDB-Tabellenräumen zur Verbesserung der Wiederherstellungszeiten nach Abstürzen für RDS für MySQL Jede Tabelle in MySQL besteht aus einer Tabellendefinition, Daten und Indizes. Die MySQL-Speicher-Engine InnoDB speichert Tabellendaten und Indizes in einem *Tabellenraum*. InnoDB erstellt einen globalen, freigegebenen Tabellenraum, der ein Datenverzeichnis und andere relevante Metadaten enthält, und kann Tabellendaten und Indizes enthalten. InnoDB kann darüber hinaus für jede Tabelle und Partition eigene Tabellenräume erstellen. Diese getrennten Tabellenräume werden in Dateien mit der Erweiterung .ibd gespeichert. Die Kopfzeile der einzelnen Tabellenräume enthalten eine Zahl, welche diese eindeutig identifiziert. Amazon RDS stellt in einer MySQL-Parametergruppe einen Parameter namens berei `innodb_file_per_table`. Dieser Parameter steuert, ob InnoDB neue Tabellendaten und Indizes in den gemeinsamen Tabellenraum (durch Setzen des Parameterwertes auf 0) oder in einzelne Tabellenräume (durch Setzen des Parameterwertes auf 1) einfügt. Amazon RDS legt den Standardwert für `innodb_file_per_table` auf 1, mit dem Sie einzelne InnoDB-Tabellen löschen und Speicher zurückgewinnen können, der von diesen Tabellen für die DB-Instance verwendet wird. In der Mehrzahl der Anwendungsfälle stellt die Festlegung des Parameters `innodb_file_per_table` auf 1 die empfohlene Einstellung dar. Sie sollten den Parameter `innodb_file_per_table` auf 0 festlegen, wenn es eine große Zahl von Tabellen gibt, beispielsweise mehr als 1 000 Tabellen, wenn Sie einen Standard-SSD-Speicher (magnetisch) oder einen SSD-Speicher für allgemeine Zwecke verwenden, oder mehr als 10 000 Tabellen, wenn Sie Speicher mit bereitgestellten IOPS verwenden. Wenn Sie diesen Parameter auf 0 festlegen, werden keine einzelnen Tabellenräume erstellt. Dies kann die Zeit für die Datenbankwiederherstellung nach einem Absturz verkürzen. MySQL verarbeitet während des Wiederherstellungszyklus nach Abstürzen jede Metadatendatei, die Tabellenräume enthält. Die Zeit, die MySQL für die Verarbeitung der Metadateninformationen im freigegebenen Tabellenraum benötigt, ist im Vergleich zu der Zeit, die für die Verarbeitung von Tausenden von Tabellenraumdateien benötigt wird, vernachlässigbar, wenn es mehrere Tabellenräume gibt. Da die Tabellenraumnummer in den Kopfzeilen der einzelnen Dateien gespeichert wird, kann die Gesamtzeit für das Lesen aller Tabellenraumdateien mehrere Stunden betragen. Beispielsweise kann die Verarbeitung von einer Million InnoDB-Tabellenräumen in einem Standardspeicher während eines Wiederherstellungszyklus nach einem Absturz zwischen fünf und acht Stunden betragen. In einigen Fällen kann InnoDB feststellen, dass im Anschluss an einen Wiederherstellungszyklus nach einem Absturz eine zusätzliche Bereinigung erforderlich ist. Dann wird ein weiterer Absturzwiederherstellungszyklus gestartet, was die Wiederherstellungszeit verlängert. Denken Sie daran, dass ein Absturzwiederherstellungszyklus zusätzlich zur Verarbeitung von Tabellenrauminformationen auch Rollbacks von Transaktionen, die Reparatur beschädigter Seiten und andere Operationen umfasst. Da sich der Parameter `innodb_file_per_table` in einer Parametergruppe befindet, können Sie den Parameterwert ändern, indem Sie die von Ihrer DB-Instance verwendete Parametergruppe bearbeiten, anstatt die DB-Instance neu starten zu müssen. Nach dem Ändern der Einstellung, beispielsweise von 1 (Erstellen einzelner Tabellen) in 0 (Verwenden freigegebener Tabellenräume) werden dem freigegebenen Tabellenraum neue InnoDB-Tabellen hinzugefügt, während die vorhandenen Tabellen weiterhin über einzelne Tabellenräume verfügen. Um eine InnoDB-Tabelle zum freigegebenen Tabellenraum zu verschieben, müssen Sie den Befehl `ALTER TABLE` verwenden. ## Migrieren mehrerer Tabellenräume zum freigegebenen Tabellenraum Sie können die Metadaten einer InnoDB-Tabelle vom eigenen Tabellenraum zum freigegebenen Tabellenraum verschieben. Hierdurch werden die Tabellenmetadaten entsprechend der Parametereinstellung `innodb_file_per_table` neu erstellt. Stellen Sie zunächst eine Verbindung mit Ihrer MySQL-DB-Instance her und geben Sie anschließend den entsprechenden Befehl aus, wie im Folgenden gezeigt. Weitere Informationen finden Sie unter [Herstellen einer Verbindung mit Ihrer MySQL-DB-Instance](USER_ConnectToInstance.md). ``` ALTER TABLE table_name ENGINE = InnoDB, ALGORITHM=COPY; ``` Zum Beispiel gibt die folgende Abfrage für jede nicht im freigegebenen Tabellenraum enthaltene InnoDB-Tabelle eine `ALTER TABLE`-Anweisung zurück. **Für MySQL 5.7 DB-Instances:** ``` SELECT CONCAT('ALTER TABLE `', REPLACE(LEFT(NAME , INSTR((NAME), '/') - 1), '`', '``'), '`.`', REPLACE(SUBSTR(NAME FROM INSTR(NAME, '/') + 1), '`', '``'), '` ENGINE=InnoDB, ALGORITHM=COPY;') AS Query FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE SPACE <> 0 AND LEFT(NAME, INSTR((NAME), '/') - 1) NOT IN ('mysql',''); ``` **Für MySQL 8.4- und 8.0-DB-Instances:** ``` SELECT CONCAT('ALTER TABLE `', REPLACE(LEFT(NAME , INSTR((NAME), '/') - 1), '`', '``'), '`.`', REPLACE(SUBSTR(NAME FROM INSTR(NAME, '/') + 1), '`', '``'), '` ENGINE=InnoDB, ALGORITHM=COPY;') AS Query FROM INFORMATION_SCHEMA.INNODB_TABLES WHERE SPACE <> 0 AND LEFT(NAME, INSTR((NAME), '/') - 1) NOT IN ('mysql',''); ``` Die Neuerstellung einer MySQL-Tabelle, um die Metadaten der Tabelle zum freigegebenen Tabellenraum zu verschieben, erfordert vorübergehend zusätzlichen Speicherplatz, um die Tabelle neu zu erstellen. Daher muss die DB-Instance über freien Speicherplatz verfügen. Während der Neuerstellung ist die Tabelle gesperrt und für Abfragen nicht verfügbar. Im Fall kleiner Tabellen oder von Tabellen, auf die nicht häufig zugegriffen wird, stellt dies möglicherweise kein Problem dar. Im Fall großer Tabellen oder von Tabellen, auf die in einer stark gleichzeitigen Umgebung häufig zugegriffen wird, können Sie Tabellen in einem Lesereplikat neu erstellen. Sie können ein Lesereplikat erstellen und Tabellenmetadaten zum freigegebenen Tabellenraum in dem Lesereplikat verschieben. Die Anweisung ALTER TABLE sperrt zwar den Zugriff auf das Lesereplikat, die Quell-DB-Instance ist hiervon jedoch nicht betroffen. Die Quell-DB-Instance generiert weiterhin Binärprotokolle, während das Lesereplikat während der Neuerstellung der Tabelle folgt. Da für die Neuerstellung zusätzlicher Speicherplatz benötigt wird und die Wiedergabeprotokolldatei sehr groß werden kann, sollten Sie ein Lesereplikat erstellen, dessen Speicher größer als der der Quell-DB-Instance ist. Führen Sie die folgenden Schritte aus, um ein Lesereplikat zu erstellen und InnoDB-Tabellen, die den freigegebenen Tabellenraum verwenden sollen, neu zu erstellen: 1. Stellen Sie sicher, dass die Sicherungsbeibehaltung in der Quell-DB-Instance aktiviert ist, damit die Binärprotokollierung aktiviert ist. 1. Verwenden Sie das AWS-Managementkonsole oder AWS CLI , um eine Read Replica für die Quell-DB-Instance zu erstellen. Da die Erstellung eines Lesereplikats viele derselben Verfahren umfasst wie eine Wiederherstellung nach einem Absturz, kann der Erstellungsvorgang eine Weile dauern, wenn es eine große Zahl von InnoDB-Tabellenräumen gibt. Teilen Sie dem Lesereplikat mehr Speicherplatz zu, als zurzeit in der Quell-DB-Instance verwendet wird. 1. Wenn das Lesereplikat erstellt wurde, erstellen Sie eine Parametergruppe mit den Parametereinstellungen `read_only = 0` und `innodb_file_per_table = 0`. Ordnen Sie dann die Parametergruppe dem Lesereplikat zu. 1. Führen Sie die folgende SQL-Anweisung für alle Tabellen aus, die auf dem Replikat migriert werden sollen: ``` ALTER TABLE name ENGINE = InnoDB ``` 1. Wenn alle `ALTER TABLE`-Anweisungen für das Lesereplikat ausgeführt wurden, überprüfen Sie, ob das Lesereplikat mit der Quell-DB-Instance verknüpft ist und die beiden Instances synchronisiert sind. 1. Verwenden Sie die Konsole oder CLI, um das Lesereplikat als Instance hochzustufen. Achten Sie darauf, dass für die Parametergruppe, die für die neue eigenständige DB-Instance verwendet wird, der Parameter `innodb_file_per_table` auf 0 festgelegt ist. Ändern Sie den Namen der neuen eigenständigen DB-Instance, und verweisen Sie alle Anwendungen auf die neue eigenständige DB-Instance. # Verwalten des globalen Statusverlaufs für RDS für MySQL **Tipp** Zum Analysieren der Datenbankleistung können Sie auch Performance Insights in Amazon RDS verwenden. Weitere Informationen finden Sie unter [Überwachung mit Performance Insights auf Amazon RDS](USER_PerfInsights.md). MySQL besitzt zahlreiche Statusvariablen, die Informationen zur Ausführung bereitstellen. Ihre Werte können Ihnen helfen, Probleme mit Sperren oder Arbeitsspeichern in einer DB-Instance zu entdecken. Die Werte dieser Statusvariablen sind seit dem letzten Zeitpunkt, an dem die DB-Instance gestartet wurde, kumulativ. Sie können die meisten Statusvariablen auf 0 zurücksetzen, indem Sie den Befehl `FLUSH STATUS` verwenden. Um die Überwachung dieser Werte über die Zeit zu ermöglichen, stellt Amazon RDS einen Satz von Verfahren bereit, die Snapshots der Werte dieser Statusvariablen über die Zeit erstellen und diese zusammen mit allen Änderungen seit dem letzten Snapshot in eine Tabelle schreiben. Diese Infrastruktur wird als globaler Statusverlauf (Global Status History, GoSH) bezeichnet und ist auf allen MySQL-DB-Instances ab Version 5.5.23 installiert. GoSH ist standardmäßig deaktiviert. Um GoSH zu aktivieren, müssen Sie zunächst den Ereignis-Scheduler aus einer DB-Parametergruppe aktivieren, indem Sie den Parameter `event_scheduler` auf `ON` festlegen. Setzen Sie darüber hinaus für MySQL-DB-Instances unter MySQL 5.7 den Parameter `show_compatibility_56` auf `1`. Weitere Informationen zum Erstellen und Ändern einer DB-Parametergruppe finden Sie unter [Parametergruppen für Amazon RDS](USER_WorkingWithParamGroups.md). Informationen zu den Nebeneffekten bei Aktivierung dieses Parameters finden Sie unter.[show\$1compatibility\$156](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_show_compatibility_56) im *Referenzhandbuch zu MySQL 5.7*. Sie können anschließend die Verfahren in der folgenden Tabelle verwenden, um GoSH zu aktivieren und zu konfigurieren. Stellen Sie zunächst eine Verbindung mit Ihrer MySQL-DB-Instance her und geben Sie anschließend den entsprechenden Befehl aus, wie im Folgenden gezeigt. Weitere Informationen finden Sie unter [Herstellen einer Verbindung mit Ihrer MySQL-DB-Instance](USER_ConnectToInstance.md). Führen Sie für jede Prozedur den folgenden Befehl aus und ersetzen Sie ihn **procedure-name**: ``` CALL procedure-name; ``` In der folgenden Tabelle sind alle Verfahren aufgeführt, die Sie **procedure-name**im vorherigen Befehl verwenden können. | Verfahren | Beschreibung | | --- | --- | | `mysql.rds_enable_gsh_collector` | Aktiviert GoSH, um Standard-Snapshots in zeitlichen Abständen zu erstellen, die durch angegeben werde `rds_set_gsh_collector`. | | `mysql.rds_set_gsh_collector` | Gibt den zeitlichen Abstand in Minuten für die periodische Generierung von Snapshots an. Der Standardwert ist 5. | | `mysql.rds_disable_gsh_collector` | Deaktiviert Snapshots. | | `mysql.rds_collect_global_status_history` | Generiert einen Snapshot auf Anforderung. | | `mysql.rds_enable_gsh_rotation` | Aktiviert die Rotation der Inhalte der Tabelle `mysql.rds_global_status_history` zu `mysql.rds_global_status_history_old` in zeitlichen Abständen, die durch `rds_set_gsh_rotation` angegeben werden. | | `mysql.rds_set_gsh_rotation` | Gibt den zeitlichen Abstand in Tagen für die periodische Tabellenrotation an. Der Standardwert ist 7. | | `mysql.rds_disable_gsh_rotation` | Deaktiviert die Tabellenrotation. | | `mysql.rds_rotate_global_status_history` | Rotiert die Inhalte der Tabelle `mysql.rds_global_status_history` bei Anforderung zu `mysql.rds_global_status_history_old`. | Wenn GoSH ausgeführt wird, können Sie Abfragen für die Tabellen ausführen, in die GoSH schreibt. Um beispielsweise eine Abfrage für das Trefferverhältnis des InnoDB-Pufferpools auszuführen, würden Sie die folgende Abfrage ausgeben: ``` select a.collection_end, a.collection_start, (( a.variable_Delta-b.variable_delta)/a.variable_delta)*100 as "HitRatio" from mysql.rds_global_status_history as a join mysql.rds_global_status_history as b on a.collection_end = b.collection_end where a. variable_name = 'Innodb_buffer_pool_read_requests' and b.variable_name = 'Innodb_buffer_pool_reads' ``` # Konfigurieren der Pufferpoolgröße und der Redo-Protokollkapazität in MySQL 8.4 In MySQL 8.4 aktiviert Amazon RDS den Parameter `innodb_dedicated_server` standardmäßig. Mit dem Parameter `innodb_dedicated_server` berechnet die Datenbank-Engine die Parameter `innodb_buffer_pool_size` und `innodb_redo_log_capacity`. Informationen zur Berechnung dieser Parameter finden Sie unter [Konfigurieren der Größe des InnoDB-Buffer-Pools](https://dev.mysql.com/doc/refman/8.4/en/innodb-buffer-pool-resize.html) und [Redo-Protokoll](https://dev.mysql.com/doc/refman/8.4/en/innodb-redo-log.html) in der MySQL-Dokumentation. Wenn `innodb_dedicated_server` aktiviert ist, wird der Parameter `innodb_buffer_pool_size` basierend auf dem DB-Instance-Klassenspeicher berechnet. Die folgende Tabelle zeigt den erkannten Serverspeicher und die entsprechende Puffergröße. | Serverspeicher wurde erkannt | Pufferpoolgröße | | --- | --- | | 1 GB | Der Standardwert ist 128 MB | | 1 GB bis 4 GB | *Detected server memory*\$1 0,5 | | 4 GB | *Detected server memory*\$1 0,75 | Der `innodb_redo_log_capacity` Parameter skaliert automatisch mit der Instanzklasse auf (Anzahl v CPUs /2) GB bis zu einem Maximum von 16 GB. Größere Instance-Klassen verfügen über eine größere Redo-Protokollkapazität, wodurch die Leistung und Stabilität bei schreibintensiven Workloads verbessert werden kann. Stellen Sie vor dem Upgrade von MySQL 8.0 auf MySQL 8.4 sicher, dass Sie Ihren Speicherplatz vergrößern, um eine mögliche Vergrößerung der Redo-Protokolle zu bewältigen, die nach Abschluss des Upgrades auftreten kann. Weitere Informationen finden Sie unter [Steigern der DB-Instance-Speicherkapazität](USER_PIOPS.ModifyingExisting.md). Wenn Sie nicht möchten, dass der Parameter `innodb_dedicated_server` die Werte für die Parameter `innodb_buffer_pool_size` und `innodb_redo_log_capacity` berechnet, können Sie diese Werte überschreiben, indem Sie spezifische Werte für sie in einer benutzerdefinierten Parametergruppe festlegen. Alternativ können Sie den Parameter `innodb_dedicated_server` deaktivieren und Werte für die Parameter `innodb_buffer_pool_size` und `innodb_redo_log_capacity` in einer benutzerdefinierten Parametergruppe festlegen. Weitere Informationen finden Sie unter [Standard- und benutzerdefinierte Parametergruppen](parameter-groups-overview.md#parameter-groups-overview.custom). Wenn Sie den Parameter `innodb_dedicated_server` deaktivieren, indem Sie ihn auf `0` festlegen und keine Werte für die Parameter `innodb_buffer_pool_size` und `innodb_redo_log_capacity` festlegen, setzt Amazon RDS die beiden letztgenannten Parameter auf 128 MB bzw. 100 MB. Diese Standardwerte führen zu einer schlechteren Leistung bei größeren Instance-Klassen.