Durch die Einführung von dynamisch verstellbaren Redo Logs mit der Version 8.0.30 gewinnen MySQL-Administratoren deutlich an Flexibilität. Standardmäßig wird die Größe der InnoDB Redo Logs, ähnlich wie auch der InnoDB Buffer, bei der Serverinitialisierung definiert. Bis dato war ein Server Restart für die Anpassung der InnoDB-Redo-Log-Größe notwendig. Dieser Restart fällt nun weg. 

Nutzen der InnoDB Redo Logs

Die InnoDB Redo Logs sind in erster Linie für den Schutz vor Datenverlust bei Transaktionen zuständig. Ähnlich wie auch bei einer Oracle-Datenbank werden Änderungen an Datensätzen zunächst im Redo Log protokolliert, bevor der eigentliche Datensatz im Buffer verändert wird. Synchron zur Transaktion/zum Commit werden diese Redo-Log-Informationen aus dem Memory in die physikalischen Redo-Log-Dateien geschrieben. Ohne ein Logging in dieses Protokoll wären Änderungen bei einem Servercrash verloren und Datenverlust eine Realität. Mit dem sogenannten WAL(Write-Ahead-Logging)-Prinzip werden die Änderungen aus dem Buffer I/O in die Logs geschrieben und können somit im Crash-Fall performant restauriert (recovered) werden. 

Die Redo Log File Capacity

​Um die Redo Logs dynamisch skalieren zu können, muss der Parameter innodb_redo_log_capacity verwendet werden. Die zuvor genutzten Parameter innodb_log_file_size * innodb_log_files_in_group sind ab diesem Moment wirkungslos und dienen nur noch der Herleitung für den Wert der Redo Log Capacity:

innodb_log_group_capacity = innodb_log_file_size * innodb_log_files_in_group

In unserem Beispiel ergibt sich der Wert für innodb_log_group_capacity daher mathematisch wie folgt:

innodb_log_group_capacity = 50331648 * 2 

Solange kein explizites Verzeichnis über den Parameter innodb_log_group_home_dir gesetzt wird, werden die InnoDB Redo Log Files in das Datadir der Datenbank gelegt. Hier existiert fortan ein Unterverzeichnis mit dem Namen #innodb_redo. Innerhalb dieses Verzeichnisses liegen zwei verschiedene Arten von Redo Log Files: Ordinary & Spare. Während es sich bei den Ordinary Files um solche handelt, die gerade verwendet werden, warten die Spare Files noch auf ihren Einsatz. Insgesamt existieren in unserem Beispiel 32 Files, die sich anteilig aus der Größe des Parameters innodb_redo_log_capacity ergeben: 

In unserem Beispiel sind fast alle Files noch ungenutzt (Spare), was sich an dem Suffix _tmp erkennen lässt. Ohne großen Aufwand lassen sich die Redo Logs nun online anpassen: 

Es gibt eine Vielzahl an Parametern, die den Status der Redo Logs beschreiben: 

Ob die dynamischen Redo Log Files aktuell verwendet werden können und somit kein Problem vorliegt, sagt beispielsweise die Variable innodb_redo_log_resize_status aus. Für weitere Infos verweise ich an dieser Stelle gerne auf die offizielle Dokumentation.

Fazit

Durch die Möglichkeit, die Redo-Log-Größe dynamisch anzupassen, liefert MySQL weitere Pluspunkte im Hinblick auf einen Enterprise fähigen Betrieb. Die Gelegenheiten für einen potenziell notwendigen Restart werden Schritt für Schritt reduziert und die Administration optimiert. Das Handling ist sehr einfach und ermöglicht eine unkomplizierte Anpassung im laufenden Betrieb. 

Exkurs: Wie groß sollten die Redo Logs sein?

Grundsätzlich sollte diese Frage immer in Absprache mit der Anwendung beantwortet werden. Als Faustregel kann hierfür die Änderungsrate der Log Sequence innerhalb einer Minute herangezogen werden: 

Innerhalb von 60 Sekunden habe ich 2-mal die „sakila“-Datenbank erstellt und wieder gelöscht. Die Log Sequence hat sich dementsprechend erhöht. Anhand der Differenz lässt sich nun das Log Volume pro Minute errechnen: 

Eine Empfehlung lautet hier, dass die Logs mindestens eine Stunde an Transaktionen halten sollten. In diesem Fall würde dies eine Log File-Größe von 18 MB * 60 = 1080 MB, also ca. 1 GB bedeuten. Für dieses Beispiel könnten wir den Parameter innodb_redo_log_capacity also auf 1 GB setzen. Die 32 einzelnen Redo Log Files würden entsprechend angepasst werden. 

Seminarempfehlung