Immer wieder kommt es bei Kunden vor, dass Datenbanken wachsen, da historische Inhalte nicht gelöscht oder archiviert werden. Oftmals handelt es sich bei diesen Daten um Zeitreihenwerte. Dies können beispielsweise erstellte Rechnungen oder erzeugte und gespeicherte Messwerte über mehrere Monate und Jahre sein. Ein mögliches Archivierungskonzept kann die beiden von MySQL unterstützten Funktionalitäten „Partitionierung" und „Replikation" verwenden.

Im Folgenden wird ein – an einen Kunden angelehntes – Archivierungskonzept erläutert, welches exakt diese Technologien implementiert hat.

Zahlen bitte! 

Im konkreten Fall hat ein Kunde in einem Warenwirtschaftssystem Rechnungen für Kunden gespeichert.​ Da die Anzahl der Rechnungen (anders als im Beispiel) über die vergangenen Jahren stark angewachsen sind, wurden diese Daten partitioniert

Teile und herrsche!

Aktuell werden die entsprechenden Rechnungen über das Datenmodell nach Jahren partitioniert. ​ Bei Zugriffen nach bestimmten Jahren, kann sich die Datenbank gezielt auf einzelne Partitionen konzentrieren. So wird beispielsweise bei bestimmten SELECTs aus einem Full-Table-Scan „nur" ein Full-Partition-Scan: ​ Da auf dem produktiven System aus unterschiedlichen Gründen jedoch nicht alle Daten gehalten werden sollen, werden regelmäßig alte Daten gelöscht. Diese müssen aber zuvor archiviert werden (z.B. aus regulatorischen Gründen). Anstatt diese Daten klassisch zu entladen (Export), um sie dann ggfs. auf einem anderen System (Reporting-Datenbank / Datawarehouse) wieder zu laden, wird hier eine Replikation genutzt. ​

Bitte (nicht) nachmachen!

Generell ist es die Aufgabe eines Replikations-Systems (wird bei MySQL Slave genannt), die Kommandos (Transaktionen) des führenden Systems (Master genannt) analog durchzuführen. Dazu werden die Daten (Transaktionen) aus einem Logfile vom Master auf den Slave kopiert und dort wiederholt.

Vor dem Jahreswechsel wird auf dem Master eine neue Partition für die Rechnungen hinzugefügt. Auch dieses Kommando vollzieht der Slave nach, um für die kommenden Rechnungen gewappnet zu sein.

Nach dem Jahreswechsel wird im Gegenzug eine alte Partition auf dem Master gelöscht, um den Datenbestand zu verrringern. Dies soll auf dem Slave jedoch nicht passieren. Um die Replikation dieses Kommandos zu unterdrücken, wird in der entsprechenden Session das Loggen auf dem Master (für dieses eine Kommando) deaktiviert.

Das Löschen der Partition wird somit vom Slave nicht durchgeführt. Die Daten bleiben also dort erhalten.

Im Normalfall sollte dieses „Schieflage" zu keinen Problem bei der Replikation führen. Auf dem Master können ja keine Daten manipuliert werden, die zu einem Abbruch der Replikation führen können. Natürlich gibt es Ausnahmen von diesem „Normalfall". Würde man versuchen auf dem Master eine „historische" Partition wieder anzulegen (die auf dem Slave noch existiert), so würde dies zu einem Fehler führen. Der Slave würde ja ebenfalls versuchen diese Partition anzulegen. Dies würde jedoch nicht funktionieren, da eine gleichnamige Partition bei ihm ja noch existiert.

Wenn Sie Fragen zur MySQL Replikation, zur Partitionierung, Archivierungslösungen oder großen Datenmengen im Umfeld von MySQL (oder MariaDB) haben, dann sprechen Sie uns gerne an.