Sensible Daten sicher speichern (Datei-Management)

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Sensible Daten sicher speichern (Datei-Management)

    Hallo Leute!

    Die Verwendung einer Datenbank-Tabelle ist, obwohl sich deren Benutzung empfehlen würde, nicht immer sinnvoll; so meine Ansicht. In einigen Fällen, wie z.B. bei Smilies, müssen bei jedem Seitenaufruf alle Datensätze aus der Tabelle ausgelesen werden, um die Smilies benutzen zu können. Daher habe ich mir gedacht, anstelle einer Tabelle, einfach eine Datei zu verwenden.
    Der Inhalt der Datei ist ein serialisiertes Array, das beim Abruf einfach wieder unserialisiert wird. Diese Methode ist auch schneller als das Auslesen aus einer Tabelle.
    Die Datei wird ebenfalls, wie eine herkömmliche Tabelle, über ein Admin-Panel mit Inhalt gefüllt. Jedoch ist das Ändern ein wenig aufwendiger, da bei Änderungen immer die ganze Datei neu geschrieben wird. Aber bei nicht mehr als einigen Duzend Smilies (um bei diesem Bsp. zu bleiben) sollte das kein Problem darstellen.

    Nun aber meine Frage:
    Wie kann ich 100%ig sicher stellen, dass die Daten nicht verloren gehen?
    Bei einer Tabelle hat man noch eine gewisse Sicherheit. Aber sollte es einmal bei der Datei zu einem Schreibfehler kommen, wenn man also Änderungen vornehmen möchte und der Server macht während der Übertragung schlapp, dann sind alle Daten verloren. Sie können auch nicht rückgewonnen werden, da die Daten ja nur in der Datei gespeichert waren.
    arrays sind klasse

  • #2
    Re: Sensible Daten sicher speichern (Datei-Management)

    Änderungen in neue Datei schreiben - und nur wenn das erfolgreich abgeschlossen wird, alte Datei entfernen und neue Datei mit Namen der alten umbenennen.

    Dabei ggf. Gedanken über sinnvolles Locking machen.
    I don't believe in rebirth. Actually, I never did in my whole lives.

    Kommentar


    • #3
      Wie gut wäre es mit einem Backup in form einer Zweitdatei, die gz-komprimiert ist, und nur dann ebenfalls neugeschrieben wird, wenn die Original-Datei erfolgreich neugeschrieben werden konnte?
      Wäre das auch 100%ig sicher?
      arrays sind klasse

      Kommentar


      • #4
        Original geschrieben von Maranello-550
        Wie gut wäre es mit einem Backup in form einer Zweitdatei, die gz-komprimiert ist, und nur dann ebenfalls neugeschrieben wird, wenn die Original-Datei erfolgreich neugeschrieben werden konnte?
        Was, wenn das Schreiben der Backupdatei nach dem Neuschreiben des Originals schiefgeht?
        Was, wenn dies zwei mal hintereinander passiert?
        Dann hast du entweder gar kein Backup mehr, oder eins, das nicht mehr aktuell ist.
        I don't believe in rebirth. Actually, I never did in my whole lives.

        Kommentar


        • #5
          Es wird ja ohnehin zyklisch ein Backup von allem gemacht, nicht wahr?

          Falls du Recoverability auf Transaktionsebene haben willst/mußt, die dir MySQL auch bei "Extended-Logging" nicht bieten kann, brauchst du 3 Dateien.

          Da serialisierte Files nicht indexiert sind, betrifft jede Transaktion immer die gesamte Datei: Transaktionssicherheit = "Dateioperationssicherheit".

          Den Erfolg einer (schreibenden) Dateioperation sicherzustellen, heißt
          1. die geplante Aktion erstmal in ein Log zu schreiben (File 1)
          2. die Aktion auszuführen (File 2) und
          3. die Aktion auch auf die Kopie (File 3) von File 2 anzuwenden

          Der nächste Schritt wird dabei nur angegangen, wenn der vorherige erfolgreich war.
          Geht 1. schief, wird es einfach wiederholt. Die Datendateien sind noch unverändert.
          Geht 2. schief, wird File 2 aus File 3 wieder hergestellt und Schritt 2 wird wiederholt.
          Geht 3. schief, wird File 3 aus File 2 minus dem letzten Eintrag in File 1 wieder hergestellt und Schritt 3 wiederholt.

          Die Lösung mit Logfile klingt umständlich, besonders das Recovery der Sicherungskopie File 3 aus der Arbeitsdatei File 2 minus dem letzten Logeintrag. Aber es sie hat den Vorteil, dass man allein aus einem entsprechend organisierten Logfile jeden beliebigen Status von File 2 und 3 reproduzieren kann.
          Verwendet man nur zwei Dateien, kopiert die eine nach erfolgreichem Schreiben auf die andere ("Backup machen") und schmiert in dem Moment der Server ab, sind u.U. beide Dateien im Ar***.
          Verwendet man eine dritte Datei, ist diese während des Absturzes nicht in Gebrauch, hat also eine höhere Überlebenschance.
          Diese dritte Datei kann natürlich auch nur eine einfache Kopei sein. Aber bei großen Datenmengen (und besonders bei wenigen Manipulationen) ist ein Logfile kleiner, performanter und wie schon erwähnt mächtiger.

          Mindestens das Logfile sollte auf einer physikalisch getrennten Platte liegen, am besten alle drei Dateien.
          Außerdem sollten jede Datei nach einer Schreiboperation zurück auf die Platte geflusht werden. Erst dann kann das Schreiben als erfolgreich angesehen werden. Das Filesystem muß das natürlich unterstützen.


          Ich habe mir das jetzt einfach so aus den Fingern geschrieben. Freue mich über Kommentare, ob das wirklich sicher ist oder vielleicht einfacher geht.
          Zuletzt geändert von onemorenerd; 27.05.2006, 22:08.

          Kommentar


          • #6
            Schaut mal hier:
            http://www.php-resource.de/forum/sho...threadid=71508

            arrays sind klasse

            Kommentar

            Lädt...
            X