Das MySQL Binary Log hat eine besondere Bedeutung gerade beim Betrieb von kritischen Datenbanken. Es ist der Dreh- und Angelpunkt für DR- und/oder Backup-Konzepte. Wir haben bereit an vielen Stellen in diesem Blog über den Mechanismus und Nutzen dieses „Log-Files" gesprochen. Mit der Version 8.0.20 besteht nun die Möglichkeit eine Komprimierung zu nutzen. Darüber wollen wir im folgenden Blog-Artikel berichten.

Luft ablassen?

Warum aber sollte man Transaktionen komprimiert protokollieren? In der Vergangenheit haben wir viele Systeme beim Kunden gesehen, auf denen die angehäuften Transaktionsprotokolle mehr Platz in Anspruch genommen haben, als die eigentlichen Daten. Im besten Fall werden im Rahmen eines Backupkonzeptes die Log-Dateien auf andere Storage-Bereiche verlagert (physikalische Separierung vom DB-Server) und benötigen dort den entsprechenden Platz. Hier kann natürlich das Einsparpotential der Komprimierung ebenfalls genutzt werden.

Aber auch in HA-/DR-Konzepten können „schlankere" Logs von Vorteil sein. Die Informationen müssen durch das Netz zum sekundären System gesendet werden. Hier bringt die kleinere Größe natürlich ebenfalls einen Vorteil.

Die Aktivierung der Komprimierung kann dynamisch (also zur Laufzeit ohne Neustart des Servers) aktiviert werden. Der Parameter „—binlog-transaction-compression[={OFF|ON}]" kann dabei generell (serverweit) oder session-spezifisch vorgenommen werden.

mysql> set global binlog_transaction_compression=1;

Neben der Aktivierung der Kompression kann der Grad (Aufwand) der Komprimierung (--binlog-transaction-compression-level-zstd=#) eingestellt werden. Hier steht ein Wert von 1 bis 22 (3 ist der Standard) zur Verfügung.

mysql> set global binlog_transaction_compression_level_zstd=3

 Ohne Fleiß…

Natürlich wird sich, wie immer im Leben, ein Vorteil (weniger I/O, Plattenplatz, Netzwerk-Traffic) immer durch einen Nachteil erkauft. Hier „zahlen" wir mit dem stärkeren Einsatz von CPU. Bevor man sich also entscheidet, ob und wie stark man in die Komprimierung der Binlogs „investiert", sollte man sich sehr ausführlich mit dem System (OS und DB) beschäftigen. Hier ein paar grundlegende Fragen:

• wie stark ist die CPU-Auslastung?
• habe ich ein I/O Problem; auch über hohe Schreibraten der Binlogs?
• habe ich ein Platzproblem („archivierte" Binlogs)?
• werden die Binary-Logs repliziert; gibt es ein Latenz-/Durchsatzproblem?
• …

… kein Preis

Letztendlich sollte auch der eigentliche Effekt der Komprimierung gemessen werden. Was bringt die Kompression? Hierfür stellt MySQL eine entsprechende System-Sicht zur Verfügung (im „performance_schema"):

In diesem Beispiel wurden lediglich einige wenige Daten anhand der MySQL-TestDB „sakila" geladen. Die daraus resultierenden Daten der 75 Transaktionen konnten immerhin zu 58% reduziert werden.

Fazit: Nur heiße Luft?

Sicher nicht. Die Komprimierung von Binlogs kann an einigen Stellen hilfreich sein. Vor dem Einsatz sollte man sich natürlich sicher sein und das System genauestens anschauen, um zu entscheiden, ob der Einsatz dieses Features sinnvoll ist.