Arbeiten mit InnoDB-Tablespaces zur Verbesserung der Wiederherstellungszeiten nach Abstürzen für My RDS SQL - 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.

Arbeiten mit InnoDB-Tablespaces zur Verbesserung der Wiederherstellungszeiten nach Abstürzen für My RDS SQL

Jede Tabelle in My SQL besteht aus einer Tabellendefinition, Daten und Indizes. Die My SQL Storage Engine InnoDB speichert Tabellendaten und Indizes in einem Tablespace. 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 einen Parameter in der Gruppe Meine SQL Parameter mit dem Namen bereitinnodb_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 setzt den Standardwert für den innodb_file_per_table Parameter auf 1, sodass Sie einzelne InnoDB-Tabellen löschen und den von diesen Tabellen verwendeten Speicher für die DB-Instance zurückgewinnen können. In der Mehrzahl der Anwendungsfälle stellt die Festlegung des Parameters innodb_file_per_table auf 1 die empfohlene Einstellung dar.

Sie sollten den innodb_file_per_table Parameter auf 0 setzen, wenn Sie über eine große Anzahl von Tabellen verfügen, z. B. über 1000 Tabellen, wenn Sie Standardspeicher (magnetisch) oder SSD Allzweckspeicher verwenden, oder auf über 10.000 Tabellen, wenn Sie bereitgestellten IOPS Speicher 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.

Meine SQL verarbeitet jede Metadatendatei, einschließlich Tablespaces, während des Wiederherstellungszyklus nach einem Absturz. Die Zeit, die My benötigtSQL, um die Metadateninformationen im gemeinsam genutzten Tablespace zu verarbeiten, ist vernachlässigbar gering im Vergleich zu der Zeit, die für die Verarbeitung von Tausenden von Tablespace-Dateien benötigt wird, wenn es mehrere Tablespaces 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 zuerst eine Verbindung zu Ihrer My SQL DB-Instance her und geben Sie dann die entsprechenden Befehle ein, wie im Folgenden dargestellt. Weitere Informationen finden Sie unter Verbindung zu einer DB-Instance herstellen, auf der die My SQL Database-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 My SQL 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 meine SQL 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','');

Beim Neuaufbau einer SQL Tabelle vom Typ My, um die Metadaten der Tabelle in den gemeinsam genutzten Tablespace zu verschieben, ist vorübergehend zusätzlicher Speicherplatz erforderlich, um die Tabelle neu zu erstellen. Daher muss für die DB-Instance Speicherplatz verfügbar sein. 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 ALTER TABLE Anweisung blockiert zwar den Zugriff auf die Read Replica, die Quell-DB-Instance ist 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 AWS Management Console 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.

  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. Geben Sie die folgende SQL Anweisung für alle Tabellen aus, die Sie auf das Replikat migrieren möchten:

    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 stufen CLI Sie die Read Replica zur Instanz herauf. 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.