Golb Slexa

Wer liebt sie nicht - die schönen Thüringer Alpen! Ich weiss noch, als ich Thüringer Rostbratwürsten auf dem Grill beim Brutzeln zusah wie auch den Blick über die schneebedeckten Bergkuppen genoss.

Wer den Fehler findet, kann ihn behalten :-)

Ich verwende diesen Aufruf, um Schemata auf dem Mysql Server zu dumpen:

  mysqldump –opt 
            –default-character-set=utf8 
            –flush-logs 
            –single-transaction 
            –no-autocommit 
            –result-file=”$_dumpfile” 
            ”$_dbname” 2>&1
  $myrc=$?

… und stand vor dem Phänomen, dass der Exitcode 0 war - also eigentlich den Erfolg meldet - aber es keinerlei Daten im Dump gab.

Das Betriebssystem war ein Centos8 Stream. Das Problem lag in der Option –flush-logs, die nicht ausgeführt werden konnte, da das Verzeichnis /var/log/mysql/ (warum auch immer) nicht mehr vorhanden war. Dass ein leerer Dump ohne Daten erzeugt wird und kein Exitcode > 0, ist m.E. ein Fehler im mysqldump. Und den versuche ich, zu umschiffen.

Ich habe nach dem Dump noch einen Check hinzugefügt, der das Vorhandensein auf mind. ein CREATE oder aber INSERT Statements prüft. Oder anders: wenn man eine (korrekte) leere Datenbank ohne einzige Tabelle oder auch nur 1 einzigem gesicherten Datensatz hat, würde ein Fehler beim Backup gemeldet. Ich meine, damit lässt es sich leben.

  mysqldump –opt 
            –default-character-set=utf8 
            –flush-logs 
            –single-transaction 
            –no-autocommit 
            –result-file=”$_dumpfile” 
            ”$_dbname” 2>&1
  $myrc=$?
  if [ $myrc -eq 0 ]; then
        if ! zgrep -iE ”(CREATE|INSERT)” ”$_dumpfile” >/dev/null
        then
          typeset -i local _iTables
          _iTables=$( mysql –skip-column-names –batch -e ”use $_dbname; show tables ;” | wc -l )
          if [ $_iTables -eq 0 ];
          then
            echo ”EMPTY DATABASE: $_dbname”
          else
            echo ”ERROR: no data - the dump doesn’t contain any CREATE or INSERT statement.”
            # force an error
            $myrc=1
          fi
        fi
  fi
  if [ $myrc -eq 0 ]; then
        echo ”OK”
        # Und dann hier noch komprimieren… 
        # gzip $_dumpfile”
        # … und Erfolg der Kompression auswerten
  else
        echo ”ERROR: mysqldump failed.”
  fi

Update:

1. 24.03.2022 - eine leere Datenbank würde als Fehler gemeldet - daher zähle ich mal noch die Tabellen

weiterführende Links:

1. mysql.com: mysqldump
2. mariadb.com: mysqldump
3. IML open source: IML-Backup (mein Backup Tool an unserem Institut zum lokalen Dumpen div. DBs und Backup mit Restic/ Duplicity)
4. DOCs: os-docs.iml.unibe.ch/iml-backup/

Ich habe grad in die History geschaut: 20 Jahre (!!!) nutze ich schon den meinigen Cronwrapper auf Linux/ Unix-Systemen.

Und ich bin noch immer am Aktualisieren und Verfeinern von dessen Skripten oder Dokumentation. Auch weil ich dessen Idee so mag. Alles ist OpenSource - GNU GPL 3.0.

Das Repository [1] enthält

• cronwrapper.sh - ein Wrapper - wenn man Cronjobs hat, dann stellt man den einfach mal vorn dran
• cronstatus.sh - das Skript zeigt den Status aller auf dem System befindlichen Cronjobs
• inc_cronfunctions.sh - ein Script, dass in Bash geschriebene Cronjobs gesourct werden kann, um div. nützliche Funktionen zu nutzen.
• Dokumentation im Markdown Format zur Installation und allen Features.

Der einfachste Einstieg ist, den Wrapper cronwrapper.sh zu verwenden: mit allen bestehenden Cronjobs, egal welcher Programmiersprache jene sind, lässt sich dieser ergänzen. Und man erhält out-of-the-box kleine nette Features.

• STDOUT und STDERR werden eingefangen und in ein normiertes Logfile geschrieben (ohne jenes explizit angeben zu müssen)
• Das Logfile wird normiert und ist mit grep nach Output oder Metadaten durchsuchbar

Alle Cronjobs, die den Wrapper verwenden, werden mit dem Skript cronstatus.sh aufgelistet und bewertet:

• weisen sie exitcode 0 auf?
• sind sie in der vorgegebenen Frist gestartet worden?

Diese Ausgabe kann man auch in einem Monitoring Script für die Überwachng aller Cronjobs auf seinen Systemen einbinden.

Und als Goodie gibt es ein Include file inc_cronfunctions.sh,welches hilfreich sein kann, sofern die Cronjobs in Bash geschrieben sind: eine Reihe nützlicher Funktionen werden darin bereitgestellt, um das Schreiben von “sicheren” und lesbaren Conjobs zu erleichtern.

weiterführende Links: (en)

1. Github: cronwrapper
2. Docs auf axel-hahn.de