Einführung
Eine Gemeinschaftswerkstatt speichert ihren Raumplan, die Kontaktadresse für Besucher und einen Zugangshinweis in einem gemeinsam genutzten HDFS-Ordner. Bevor du den Plan bearbeitest, brauchst du einen Wiederherstellungspunkt, der die freigegebenen Dateien auch nach Änderungen am aktuellen Ordner noch zeigt.
Zuerst liest du die normalen Daten, erstellst als gewöhnlicher Eigentümer einen nativen Snapshot und führst anschließend zwei kontrollierte Änderungen aus. HDFS-Pfade, Datei-Uploads, Verzeichnisse und grundlegende Eigentümer- und Gruppenberechtigungen solltest du bereits kennen. Dieses Lab führt Snapshots und ihre historischen Pfade ein. Verwende durchgehend Terminal; alle Daten sind unabhängig von anderen Labs. Der Autor schätzt 40 Minuten einschließlich Lesen und üblicher Fehlerkorrekturen.
Freigegebene Dateien vor dem Bearbeiten sichern
In diesem Schritt liest du den funktionierenden Veranstaltungsplan und erstellst einen benannten Wiederherstellungspunkt. Beginne in Terminal. cd ändert das lokale Arbeitsverzeichnis dieser Shell; Pfade, die in HDFS-Befehlen mit /user/labex/ beginnen, gehören zu HDFS und nicht zu deiner lokalen Festplatte.
cd /home/labex/project
Lies den aktuellen Plan:
hdfs dfs -cat /user/labex/snapshot-workshop/team/schedule.csv
Die durch Kommas getrennten Felder geben einen Raum und seine Veranstaltung an:
room,session
A,Printmaking
B,Bookbinding
Der Teamordner enthält außerdem contacts.csv und notes.txt. Zeige seinen Inhalt an:
hdfs dfs -ls /user/labex/snapshot-workshop/team
Diese normalen gemeinsam genutzten Dateien gehören labex und haben die Gruppe bigdata. Der vorbereitete Benutzer analyst ist Mitglied dieser Gruppe und darf lesen, aber nicht schreiben. Du bist der gewöhnliche Eigentümer, nicht die Dienstidentität des NameNode, hdfs. Die Lehrumgebung verwendet einfache Authentifizierung; sie demonstriert keine Kerberos-Sicherheit.
Ein Snapshot ist eine schreibgeschützte historische Ansicht eines Verzeichnisses zu einem benannten Zeitpunkt. Ein Administrator hat die Snapshot-Funktion nur für diesen Kursordner freigeschaltet. Den eigentlichen Wiederherstellungspunkt erstellst du selbst. -createSnapshot erhält das aktuelle Verzeichnis und danach den Snapshot-Namen:
hdfs dfs -createSnapshot /user/labex/snapshot-workshop/team morning-approved
Die Antwort nennt einen nativen Pfad, der auf .snapshot/morning-approved endet. Die besondere Pfadkomponente .snapshot wählt die Historie aus; sie ist kein gewöhnliches Backupverzeichnis, das du mit -mkdir erstellst. Lies den historischen Plan:
hdfs dfs -cat /user/labex/snapshot-workshop/team/.snapshot/morning-approved/schedule.csv
Er enthält dieselben zwei freigegebenen Veranstaltungen. Zeige alle drei historischen Dateien an:
hdfs dfs -ls /user/labex/snapshot-workshop/team/.snapshot/morning-approved
Der Snapshot enthält auch den ursprünglichen Kontakt und den Zugangshinweis. Meldet ein Befehl No such file or directory, vergleiche die Schreibweise mit dieser Auflistung und wiederhole nur den fehlgeschlagenen Lesezugriff. Meldet -createSnapshot, dass der Name bereits existiert, untersuche diesen Snapshot, statt ihn zu löschen oder neu anzulegen. Starte die Umgebungsvorbereitung nicht erneut: Sie verweigert das Überschreiben vorhandener Arbeit.
Du hast jetzt vor jeder Bearbeitung einen echten Wiederherstellungspunkt. Eine lokal heruntergeladene Kopie oder ein gewöhnlicher Ordner mit demselben Namen würde diese native Historie nicht erzeugen.
Historie mit späterer Arbeit vergleichen
In diesem Schritt ergänzt du gültige neue Arbeit, erzeugst einen eng begrenzten Fehler und beobachtest, dass der Snapshot unverändert bleibt. Arbeite im selben Terminal weiter.
Die Datei für die spätere Werkstattveranstaltung liegt lokal bereit. Lies sie zuerst:
cat /home/labex/project/incoming/late-session.csv
Sie enthält Raum C und Paper Folding. Lade sie in den aktuellen Teamordner hoch. Sie gehört zum aktuellen Programm und muss jede spätere Wiederherstellung überstehen:
hdfs dfs -put /home/labex/project/incoming/late-session.csv /user/labex/snapshot-workshop/team/late-session.csv
Behalte mit -chgrp die vorgesehene Freigabegruppe bei. Der Dateimodus 640 gibt dem Eigentümer Lese- und Schreibzugriff, der Gruppe Lesezugriff und anderen Benutzern keinen Dateizugriff:
hdfs dfs -chgrp bigdata /user/labex/snapshot-workshop/team/late-session.csv
hdfs dfs -chmod 640 /user/labex/snapshot-workshop/team/late-session.csv
Untersuche als Nächstes einen absichtlich falschen Ersatz:
cat /home/labex/project/incoming/schedule-draft.csv
Er enthält A,CANCELLED. Der nächste Upload überschreibt absichtlich nur die benannte aktuelle Plandatei. Die Option -f erlaubt das Ersetzen dieses Ziels; hier verwendest du sie nur für die kontrollierte Änderung. Der Snapshot bleibt davon unberührt.
hdfs dfs -put -f /home/labex/project/incoming/schedule-draft.csv /user/labex/snapshot-workshop/team/schedule.csv
Der zweite kontrollierte Fehler entfernt nur die aktuelle Kontaktdatei. Prüfe zuerst den genauen Pfad:
hdfs dfs -ls /user/labex/snapshot-workshop/team/contacts.csv
hdfs dfs -rm /user/labex/snapshot-workshop/team/contacts.csv
Verwende weder einen Platzhalter noch rekursives Löschen noch das Team-Stammverzeichnis. Lies den veränderten Plan und danach seine historische Version:
hdfs dfs -cat /user/labex/snapshot-workshop/team/schedule.csv
hdfs dfs -cat /user/labex/snapshot-workshop/team/.snapshot/morning-approved/schedule.csv
Das aktuelle Ergebnis zeigt die Absage; die Historie enthält weiterhin Printmaking und Bookbinding. Lies den historischen Kontakt mit der tatsächlichen Identität für den gemeinsamen Lesezugriff. sudo -u analyst führt nur diesen Client unter dieser gewöhnlichen Testidentität aus; der absolute Clientpfad wählt das vorbereitete HDFS-Werkzeug:
sudo -u analyst /usr/local/bin/hdfs dfs -cat /user/labex/snapshot-workshop/team/.snapshot/morning-approved/contacts.csv
Die Adresse lautet weiterhin visitors@example.test, obwohl die aktuelle Kontaktdatei fehlt. Prüfe die aktuelle Auflistung:
hdfs dfs -ls /user/labex/snapshot-workshop/team
Sie enthält den veränderten Plan, den unveränderten Hinweis und die neue Veranstaltung. Meldet der vorherige Upload der neuen Datei ein vorhandenes Ziel, lies die bestehende Datei, statt sie zu löschen und den Upload auszuweiten. Meldet ein wiederholter Löschversuch einen fehlenden Kontakt, wurde die kontrollierte Löschung bereits ausgeführt; untersuche die Auflistung und fahre fort.
Lass diesen Endzustand unverändert. Das nächste Lab stellt eine eigene unabhängige beschädigte Umgebung bereit und erklärt die Wiederherstellung. Snapshots teilen sich den Speicher mit HDFS: Ihre Blöcke sind keine unabhängigen Backupkopien. Sie schützen daher nicht vor dem Verlust des gesamten Speichersystems.
Zusammenfassung
Du hast vor dem Bearbeiten einen nativen HDFS-Snapshot erstellt und danach seine geschützten historischen Dateien vom veränderten aktuellen Ordner unterschieden. Die später hinzugefügte Veranstaltung existiert nur im aktuellen Programm. Den ganzen Ordner durch die Historie zu ersetzen würde daher gültige Arbeit verwerfen. Außerdem hast du die Historie mit der tatsächlichen Freigabeidentität analyst gelesen.
