Weniger ist mehr. MySQL Binlog Transaction Compression

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ß…

• 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"):

mysql> select * from binary_log_transaction_compression_stats where compression_type = 'ZSTD'\G
*************************** 1. row ***************************
                            LOG_TYPE: BINARY
                    COMPRESSION_TYPE: ZSTD
                 TRANSACTION_COUNTER: 75
            COMPRESSED_BYTES_COUNTER: 2811350
          UNCOMPRESSED_BYTES_COUNTER: 6617130
              COMPRESSION_PERCENTAGE: 58
                FIRST_TRANSACTION_ID: ANONYMOUS
  FIRST_TRANSACTION_COMPRESSED_BYTES: 2186
FIRST_TRANSACTION_UNCOMPRESSED_BYTES: 4310
         FIRST_TRANSACTION_TIMESTAMP: 2021-09-09 12:16:53.816784
                 LAST_TRANSACTION_ID: ANONYMOUS
   LAST_TRANSACTION_COMPRESSED_BYTES: 188
 LAST_TRANSACTION_UNCOMPRESSED_BYTES: 212
          LAST_TRANSACTION_TIMESTAMP: 2021-09-09 14:15:46.133141
1 row in set (0.00 sec)
 

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.