Optimierung der MySQL-Speicher-Engine:Konfigurieren der InnoDB-Optimierung für hohe Leistung

InnoDB ist eine der am weitesten verbreiteten Speicher-Engines in MySQL. Diese Speicher-Engine ist als hochzuverlässige und leistungsstarke Speicher-Engine bekannt und zu ihren wichtigsten Vorteilen gehören die Unterstützung von Sperren auf Zeilenebene, Fremdschlüssel und die Befolgung des ACID-Modells. InnoDB ersetzt MyISAM als Standardspeicher-Engine seit MySQL 5.5, das 2010 veröffentlicht wurde.

Diese Speicher-Engine kann unglaublich leistungsfähig und leistungsfähig sein, wenn sie richtig optimiert wird – heute werfen wir einen Blick auf die Dinge, die wir tun können, damit sie die bestmögliche Leistung erbringt, aber bevor wir abtauchen In InnoDB sollten wir jedoch verstehen, was das oben erwähnte ACID-Modell ist.

Was ist ACID und warum ist es wichtig?

ACID ist ein Satz von Eigenschaften von Datenbanktransaktionen. Das Akronym lässt sich mit vier Wörtern übersetzen:Atomicity, Consistency, Isolation und Durability. Kurz gesagt, diese Eigenschaften stellen sicher, dass Datenbanktransaktionen zuverlässig verarbeitet werden und die Datengültigkeit trotz Fehlern, Stromausfällen oder ähnlichen Problemen gewährleistet sind. Ein Datenbankverwaltungssystem, das sich an diese Prinzipien hält, wird als ACID-kompatibles DBMS bezeichnet. So funktioniert alles in InnoDB:

• Atomicity stellt sicher, dass die Aussagen in einer Transaktion als unteilbare Einheit funktionieren und dass ihre Auswirkungen gemeinsam oder gar nicht gesehen werden;
• Konsistenz wird durch die Protokollierungsmechanismen von MySQL gehandhabt, die alle Änderungen an der Datenbank aufzeichnen;
• Isolierung bezieht sich auf das Sperren auf Zeilenebene von InnoDB;
• Die Dauerhaftigkeit wird auch dadurch aufrechterhalten, dass InnoDB eine Protokolldatei verwaltet, die alle Änderungen am System verfolgt.

InnoDB verstehen

Nun, da wir ACID behandelt haben, sollten wir uns wahrscheinlich ansehen, wie InnoDB unter der Haube aussieht. So sieht InnoDB von innen aus (Bild mit freundlicher Genehmigung von Percona):

Aus dem obigen Bild können wir deutlich erkennen, dass InnoDB einige hat Parameter entscheidend für seine Leistung und diese sind wie folgt:

• Der Parameter innodb_data_file_path beschreibt den System-Tablespace (der System-Tablespace ist der Speicherbereich für das InnoDB-Datenwörterbuch, die doppelten Schreib- und Änderungspuffer und Undo-Logs). Der Parameter stellt die Datei dar, in der aus InnoDB-Tabellen abgeleitete Daten gespeichert werden;
• Der Parameter innodb_buffer_pool_size ist ein Speicherpuffer, den InnoDB verwendet, um Daten und Indizes seiner Tabellen zwischenzuspeichern;
• Der Parameter innodb_log_file_size zeigt die Größe der InnoDB-Protokolldateien an;
• Der Parameter innodb_log_buffer_size wird verwendet, um in die Protokolldateien auf der Festplatte zu schreiben;
• Der Parameter innodb_flush_log_at_trx_commit steuert das Gleichgewicht zwischen strenger ACID-Konformität und höherer Leistung;
• Der innodb_lock_wait_timeout-Parameter ist die Zeitspanne in Sekunden, die eine InnoDB-Transaktion auf eine Zeilensperre wartet, bevor sie aufgibt;
• Der Parameter innodb_flush_method definiert die Methode, die verwendet wird, um Daten in InnoDB-Datendateien und Protokolldateien zu leeren, die den E/A-Durchsatz beeinflussen können.

InnoDB speichert auch die Daten aus seinen Tabellen in einer Datei namens ibdata1 - die Protokolle werden jedoch in zwei separaten Dateien namens ib_logfile0 und ib_logfile1 gespeichert:Alle diese drei Dateien befinden sich in /var/lib/mysql Verzeichnis.

Um InnoDB so leistungsfähig wie möglich zu machen, müssen wir diese Parameter feinabstimmen und sie so weit wie möglich optimieren, indem wir unsere verfügbaren Hardwareressourcen betrachten.

Optimieren von InnoDB für hohe Leistung

Um die Leistung von InnoDB auf Ihrer Hardware anzupassen, gehen Sie folgendermaßen vor:

• Um innodb_data_file_path automatisch zu erweitern, geben Sie das Attribut autoextend in der Einstellung an und starten Sie den Server neu. Zum Beispiel:

innodb_data_file_path=ibdata1:10M:autoextend

Wenn der Autoextend-Parameter verwendet wird, wird die Datendatei jedes Mal, wenn Speicherplatz benötigt wird, automatisch um 8 MB-Schritte vergrößert. Eine neue automatisch erweiterbare Datendatei kann auch wie folgt angegeben werden (in diesem Fall heißt die neue Datendatei ibdata2):

innodb_data_file_path=ibdata1:10M;ibdata2:10M:autoextend

• Bei der Verwendung von InnoDB ist der verwendete Hauptmechanismus der Pufferpool. InnoDB ist stark vom Pufferpool abhängig, und als Faustregel sollte der Parameter innodb_buffer_pool_size etwa 60 % bis 80 % des insgesamt verfügbaren RAM auf dem Server ausmachen. Denken Sie daran, dass Sie auch etwas RAM für die Prozesse lassen sollten, die im Betriebssystem ausgeführt werden;

• innodb_log_file_size von InnoDB sollte so groß wie möglich eingestellt werden, aber nicht größer als nötig. Denken Sie in diesem Fall daran, dass eine größere Protokolldatei besser für die Leistung ist, aber je größer sie ist, desto länger ist die Wiederherstellungszeit nach einem Absturz erforderlich. Daher gibt es keine Einheitslösung, aber es wird gesagt, dass die kombinierte Größe der Protokolldateien groß genug sein sollte. Dies hilft dem MySQL-Server, regelmäßig an Checkpointing- und Festplatten-Flushing-Aktivitäten zu arbeiten. Dies spart zu viel CPU- und Festplatten-E/A und kann während der Spitzenzeiten oder Aktivitäten mit hoher Arbeitslast reibungslos ausgeführt werden. Obwohl der empfohlene Ansatz darin besteht, es selbst zu testen und zu experimentieren und den optimalen Wert selbst zu finden;

• Der innodb_log_buffer_size-Wert sollte auf mindestens 16 M festgelegt werden. Ein großer Protokollpuffer ermöglicht die Ausführung großer Transaktionen, ohne dass das Protokoll auf die Festplatte geschrieben werden muss, bevor die Transaktionen festgeschrieben werden, wodurch einige Festplatten-E/A eingespart werden;

• Beachten Sie beim Optimieren von innodb_flush_log_at_trx_commit, dass dieser Parameter drei Werte akzeptiert - 0, 1 und 2. Mit einem Wert von 1 erhalten Sie ACID-Konformität und mit den Werten 0 oder 2 erhalten Sie mehr Leistung, aber weniger Zuverlässigkeit, da in diesem Fall Transaktionen, deren Protokolle noch nicht auf die Festplatte geschrieben wurden, bei einem Absturz verloren gehen können;

• Um innodb_lock_wait_timeout auf einen richtigen Wert zu setzen, denken Sie daran, dass dieser Parameter die Zeit in Sekunden (der Standardwert ist 50) davor definiert Ausgeben des folgenden Fehlers und Zurücksetzen der aktuellen Anweisung:

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

• In InnoDB stehen mehrere Flush-Methoden zur Verfügung. Standardmäßig ist diese Einstellung auf Windows-Maschinen auf „async_unbuffered“ gesetzt, wenn der Wert auf NULL und auf Linux-Maschinen auf „fsync“ gesetzt ist. Hier ist, was die Methoden sind und was sie tun:

• Sie sollten auch die Einstellung innodb_file_per_table aktivieren. Dieser Parameter ist in MySQL 5.6 und höher standardmäßig aktiviert. Dieser Parameter entlastet Sie von Verwaltungsproblemen in Bezug auf InnoDB-Tabellen, indem er sie in separaten Dateien speichert und aufgeblähte Hauptwörterbücher und Systemtabellen vermeidet. Das Aktivieren dieser Variable vermeidet auch die Komplexität der Datenwiederherstellung, wenn eine bestimmte Tabelle beschädigt ist
• Nachdem Sie diese Einstellungen gemäß den oben beschriebenen Anweisungen geändert haben, sollten Sie fast startklar sein! Bevor Sie jedoch loslegen, sollten Sie wahrscheinlich die verkehrsreichste Datei in der gesamten InnoDB-Infrastruktur im Auge behalten – die ibdata1.

Umgang mit ibdata1

Es gibt mehrere Klassen von Informationen, die in ibdata1 gespeichert sind:

1. Die Daten von InnoDB-Tabellen;
2. Die Indizes von InnoDB-Tabellen;
3. InnoDB-Tabellenmetadaten;
4. Multiversion Concurrency Control (MVCC)-Daten;
5. Doublewrite-Puffer - ein solcher Puffer ermöglicht es InnoDB, sich von halb geschriebenen Seiten zu erholen. Der Zweck eines solchen Puffers besteht darin, Datenkorruption zu verhindern;
6. Der Einfügepuffer - ein solcher Puffer wird von InnoDB verwendet, um Aktualisierungen auf derselben Seite zu puffern, damit sie sofort und nicht nacheinander ausgeführt werden können.

Beim Umgang mit großen Datensätzen kann die ibdata1-Datei extrem groß werden, und dies kann der Kern eines sehr frustrierenden Problems sein – die Datei kann nur wachsen und standardmäßig nicht schrumpfen. Sie können MySQL herunterfahren und diese Datei löschen, aber dies wird nicht empfohlen, es sei denn, Sie wissen, was Sie tun. Nach dem Löschen funktioniert MySQL nicht mehr richtig, da das Wörterbuch und die Systemtabellen nicht mehr vorhanden sind und somit die Hauptsystemtabelle beschädigt ist.

Um ibdata1 ein für alle Mal zu verkleinern, gehen Sie folgendermaßen vor:

1. Dump alle Daten aus InnoDB-Datenbanken. Sie können für diese Aktion mysqldump oder mysqlpump verwenden;
2. Löschen Sie alle Datenbanken außer den Datenbanken mysql, performance_schema und information_schema;
3. MySQL beenden;
4. Fügen Sie Folgendes zu Ihrer my.cnf-Datei hinzu:

   [mysqld]
   innodb_file_per_table = 1
   innodb_flush_method = O_DIRECT
   innodb_log_file_size = 25% of innodb_buffer_pool_size
   innodb_buffer_pool_size = up to 60-80% of available RAM.

5. Löschen Sie die Dateien ibdata1 und ib_logfile* (diese werden beim nächsten Neustart von MySQL neu erstellt);
6. Starten Sie MySQL und stellen Sie die Daten aus dem zuvor erstellten Dump wieder her. Nachdem Sie die oben beschriebenen Schritte ausgeführt haben, wird die ibdata1-Datei immer noch wachsen, aber sie enthält nicht länger die Daten aus InnoDB-Tabellen – die Datei enthält nur Metadaten und jede InnoDB-Tabelle wird außerhalb von ibdata1 existieren. Wenn Sie nun in das Verzeichnis /var/lib/mysql gehen, sehen Sie zwei Dateien, die jede Tabelle darstellen, die Sie mit der InnoDB-Engine haben. Die Dateien werden so aussehen:
   1. demotable.frm
   2. demotable.ibd

Die .frm-Datei enthält den Speicher-Engine-Header und die .ibd-Datei enthält die Tabellendaten und Indizes Ihrer Tabelle.

Stellen Sie jedoch vor dem Rollout der Änderungen sicher, dass Sie die Parameter an Ihre Infrastruktur anpassen. Diese Parameter können die Leistung von InnoDB beeinträchtigen oder beeinträchtigen, also behalten Sie sie immer im Auge. Jetzt sollten Sie startklar sein!

Zusammenfassung

Zusammenfassend lässt sich sagen, dass die Optimierung der Leistung von InnoDB ein großer Vorteil sein kann, wenn Sie Anwendungen entwickeln, die gleichzeitig Datenintegrität und hohe Leistung erfordern – InnoDB ermöglicht es Ihnen, zu ändern, wie viel Speicher die Engine zulässt verbrauchen, die Protokolldateigröße ändern, die von der Engine verwendete Flush-Methode und so weiter - diese Änderungen können InnoDB extrem gut machen, wenn sie richtig eingestellt sind. Bevor Sie jedoch irgendwelche Erweiterungen vornehmen, achten Sie auf die Folgen Ihrer Aktionen sowohl für Ihren Server als auch für MySQL.

Wie immer, bevor Sie irgendetwas für die Leistung optimieren, erstellen (und testen!) Sie immer Backups, damit Sie Ihre Daten bei Bedarf wiederherstellen und alle Änderungen immer auf einem lokalen Server testen können, bevor Sie die Änderungen in die Produktion einführen.