HOWTO GT.M resistenter gegen Crashs sichern

minisys
2008-04-22
2012-12-29
  • minisys

    minisys - 2008-04-22

    Hallo.
    Keine Ahnung ob es irgendwen interessiert, ich habe mal durch viel Probieren und Testen eine gangbare Strategie zur Datenbestands-Sicherung entworfen und die auch realisiert. Vielleicht kann ja irgendwer etwas davon für sich gebrauchen oder irgendwer hätte noch willkommene Verbesserungsvorschläge.

    1.) Beim Starten des ersten GT.M (Mumps) Prozesses führe ich folgenden Shell-Code für eine Datenbank aus:
    -.-
    #!/bin/bash
    cd /minisys
    export gtm_dist=/minisys/gtm
    export gtmgbldir=workspace
    gtm/mupip set -reg -journal=enable,before_images "*"
    gtm/mupip set -reg -journal=on,before_images "*"
    gtm/mupip journal -recover -backward "*"
    rm workspace/*.mjl_*
    -.-

    Damit stelle ich sicher, dass das Journaling gesetzt wird (Sofern es bisher noch nicht aktiviert wurde) und führe gleich ein recover für den Fall durch, falls die vorhergehende Session gecrasht war. Gibt es keinen aktuellen Handlungsbedarf, so führt GT.M auch nix wesentliches durch. Nachdem das recover abgeschlossen ist lösche ich die Journal-Files *.mjl_*.

    2.) Zur Laufzeit, also während GT.M aktiv ist, kontrolliert ein GT.M Job im 10 Minuten Takt die Größe des aktuellen Journal-Files. Ist diese größer als ein vorgegebener Wert, z.B. 100 MB, so führe ich folgenden Shell-Code via zsy aus:
    -.-
    #!/bin/bash
    cd /minisys
    export gtm_dist=/minisys/gtm
    export gtmgbldir=workspace
    gtm/mupip set -reg -journal=on,before_images "*"
    rm workspace/*.mjl_*
    -.-

    Somit habe ich ein akives Journaling, die maximale Größe des Journalfiles ist halbwegs kalkulierbar, Eingriffe seitens des Anwenders sind nicht erforderlich und die Systembelastung hält sich in Grenzen.
    Problematisch könnte es nur werden wenn während Punkt 2 GT.M bzw. das BS crasht. Vielleicht fällt mir da auch noch was zu ein.

    Stefan

     
    • Jens Wulf

      Jens Wulf - 2009-07-19

      Vielleicht sehe ich ja was falsch, aber ich glaube, du hast ein Problem, wenn ein Job "Amok" läuft. Wenn ein GT.M-Job aus irgendeinem Grund in eine Endlosschleife kommt und dabei immer wieder neue Einträge in das Journaling schreibt, dann hast du kein brauchbares Journal mehr und der Blödsinn, den das Programm gemacht hat lässt sich nicht mehr reparieren. Eine Warnung per Mail, wenn das Journal eine bestimmte Größe überschreitet wäre schon ein Ansatz zumindest, wenn jemand regelmäßig solche Mails liest.

      Gruß

      Jens

       

Log in to post a comment.