Geläufige DBA-Aufgaben für MySQL-DB-Instances - 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.

Geläufige DBA-Aufgaben für MySQL-DB-Instances

In diesem Abschnitt werden die Amazon RDS-spezifischen Implementierungen einiger häufiger DBA-Aufgaben für DB-Instances beschrieben, in denen die MySQL-Datenbank-Engine ausgeführt wird. Um eine verwaltete Service-Erfahrung zu bieten, stellt Amazon RDS keinen Shell-Zugriff auf DB-Instances bereit, und beschränkt den Zugriff auf bestimmte Systemprozeduren und -tabellen, die erweiterte Sonderrechte erfordern.

Informationen zum Arbeiten mit MySQL-Protokolldateien in Amazon RDS finden Sie unter MySQL-Datenbank-Protokolldateien.

Beenden einer Sitzung oder Abfrage

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 Verbinden mit einer DB-Instance, auf der die MySQL-Datenbank-Engine ausgeführt wird.

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 von Fehlern für die aktuelle Replikation

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. 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 Verbinden mit einer DB-Instance, auf der die MySQL-Datenbank-Engine ausgeführt wird.

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 SLAVE STATUS\G

Informationen zu den zurückgegebenen Werten finden Sie in der MySQL-Dokumentation.

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

Wichtig

Wenn Sie versuchen, mysql.rds_skip_repl_error aufzurufen und der folgende Fehler angezeigt wird: ERROR 1305 (42000): PROCEDURE mysql.rds_skip_repl_error does not exist, müssen Sie Ihre MySQL-DB-Instance auf die neueste kleinere Version oder eine der kleineren mindestens erforderlichen Versionen aktualisieren, die in mysql.rds_skip_repl_error aufgelistet werden.

Arbeiten mit InnoDB-Tablespaces zur Verbesserung der Wiederherstellungszeiten nach Abstürzen

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, die diese eindeutig identifiziert.

Amazon RDS stellt in einer MySQL-Parametergruppe einen Parameter namens innodb_file_per_table bereit. 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 setzt den Standardwert für den Parameter innodb_file_per_table auf 1. Dies ermöglicht Ihnen das Löschen einzelner InnoDB-Tabellen und die Wiederverwendung des von diesen Tabellen verwendeten Speicherplatzes für die DB-Instance. 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 1000 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 Verbinden mit einer DB-Instance, auf der die MySQL-Datenbank-Engine ausgeführt wird.

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.6- und 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.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.

  2. Verwenden Sie die AWS Management Console oder AWS CLI, um ein Lesereplikat 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.

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

  4. Führen Sie die folgende SQL-Anweisung für alle Tabellen aus, die auf dem Replikat migriert werden sollen:

    ALTER TABLE name ENGINE = InnoDB
  5. 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.

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

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. Weitere Informationen zum Erstellen und Ändern einer DB-Parametergruppe finden Sie unter Arbeiten mit DB-Parametergruppen.

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 Verbinden mit einer DB-Instance, auf der die MySQL-Datenbank-Engine ausgeführt wird. Geben Sie für jedes Verfahren Folgendes ein:

CALL procedure-name;

Wobei procedure-name eines der Verfahren in der Tabelle ist.

Verfahren

Beschreibung

mysql.rds_enable_gsh_collector

Aktiviert GoSH, um Standard-Snapshots in zeitlichen Abständen zu erstellen, die durch rds_set_gsh_collector angegeben werden.

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'