Dieser Artikel ist im November 2019 erschienen
Für die Joyent Public Cloud hat Joyent eine recht große Anzahl an Images erstellt. Die Cloud bietet Joyent zum 09.11.2019 nicht mehr an, die Images gibt es aber weiterhin. Die Images gibt es in zwei "Geschmacksrichtungen": Eine Art von Images ist "container-native" und die andere ist für "virtual machines" gedacht. Diese Unterscheidung hat ihren Grund in den verschiedenen Virtualisierungstechniken, die auf SmartOS zur Verfügung stehen: Auf der einen Seite Zonen (aufgeteilt in "normale" Zonen und "lx-branded" Zones) und auf der anderen Seite virtuelle Maschinen auf Basis von kvm und bhyve.
Aus verschiedenen Gründen habe ich mir die Bereitstellung eines Percona-Clusters angesehen. Auf Grund einer früheren Kooperation mit Percona (und vermutlich auf Grund von Kundenwünschen) bietet Joyent ein "container-native" Image für Percona-Cluster an. Dieses enthält zusätzlich ein nützliches Paket aus dem "portable package build system" pkgsrc, welches für SmartOS verwendet wird: Joyent QuickBackup for Percona MySQL server.
Die Installation ist relativ simpel. Ich werde die einzelnen Schritte vielleicht später hier noch aufführen. Für die Einrichtung des Quickbackups sollte man zunächst einen Datenbankuser mit den entsprechenden Rechten anlegen:
mysql> CREATE USER 'bkpuser'@'localhost' IDENTIFIED BY 's3cret';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO
'bkpuser'@'localhost';
mysql> FLUSH PRIVILEGES;
Danach sollte man noch das Backupverzeichnis für den User und die Gruppe mysql schreibbar machen. Ich hatte dann das Backup auf viertelstündlich eingestellt und wollte es 14 Tage lang vorhalten bevor alte Backups gelöscht werden. Das ist noch keine fertige Backupstrategie, da das Backup bisher nur an einem Knoten des Clusters stattfindet. Es wäre zu überlegen, ob man Backups an allen drei Knoten (quasi reihum) erstellen lässt. Weiterhin wäre es sinnvoll, für ein "offsite" Backup zu sorgen, in dem man Dumps automatisch nach Manta hochlädt (z. B. mit dem folgenden Skript, welches dafür noch angepasst werden müsste) und natürlich dann zyklisch dort auch wieder löscht.
Seit dem 15.11. wird jetzt also alle 15 Minuten ein Quickbackup von dem ersten Knoten des Clusters erstellt und lokal abgelegt. Inzwischen sind auf diese Weise 670 Backupdateien zusammengekommen, von denen jede etwa 2,1 Megabyte groß ist. Wenn man ausrechnet, wieviel Plattenplatz diese 670 Dateien belegen müssten, kommt man auf ca. 1,4 Gigabyte. Die Ausgabe von du sieht dann auch so aus:
[root@pcx1 /var/backups/percona]# du --apparent-size -h .
1,4G .
[root@pcx1 /var/backups/percona]#
Tatsächlich belegen die Backups aber deutlich weniger Platz im Dateisystem:
[root@pcx1 /var/backups/percona]# du -hs .
399M .
[root@pcx1 /var/backups/percona]#
Das liegt am ZFS-Dateisystem, welches in "container-native" Zonen verwendet wird. In der Zone selbst kann man die Eigenschaften des darunter liegenden Dateisystems nicht abfragen. Auf dem Host, auf dem die Zone gestartet wurde aber schon:
[root@esxp-8391 (de-gt-2) ~]# zfs get compression |grep 48996189-9f10-42f0-a330-ec0e13b66b9f
zones/48996189-9f10-42f0-a330-ec0e13b66b9f compression lz4 inherited from zones
zones/cores/48996189-9f10-42f0-a330-ec0e13b66b9f compression lz4 inherited from zones/cores
[root@esxp-8391 (de-gt-2) ~]# zfs get compressratio |grep 48996189-9f10-42f0-a330-ec0e13b66b9f
zones/48996189-9f10-42f0-a330-ec0e13b66b9f compressratio 3.12x -
zones/cores/48996189-9f10-42f0-a330-ec0e13b66b9f compressratio 1.00x -
[root@esxp-8391 (de-gt-2) ~]#
Für das Dateisystem ist offensichtlich lz4 Kompression eingeschaltet worden, die dafür sorgt, dass die Dumps um den Faktor drei komprimiert werden können.