Aus dem Buch " Hadoop The Definitive Guide " wird unter dem Thema Nameodes und Datanodes Folgendes erwähnt:
Der namenode verwaltet den Dateisystem-Namespace. Es behält die Dateisystembaum und die Metadaten für alle Dateien und Verzeichnisse in der Baum. Diese Information wird dauerhaft auf dem lokalen Datenträger in gespeichert die Form von zwei Dateien: das Namespacebild und das Bearbeitungsprotokoll.
sekundärer Namenscode, der trotz seines Namens nicht als Namenscode dient. Seine Hauptaufgabe besteht darin, das Namespacebild regelmäßig mit dem zu verschmelzen Bearbeiten Sie das Protokoll, um zu verhindern, dass das Bearbeitungsprotokoll zu groß wird.
Ich habe etwas Verwirrung mit diesen Dateien Namespace und Protokoll bearbeiten .
Das Namespace-Bild dient zum Speichern der Metadaten.
Also, meine Fragen sind
Bitte kann mir jemand erklären, was das Bearbeitungsprotokoll ist? Welche Rolle spielt diese Protokolldatei?
Wenn der NameNode zum ersten Mal gestartet wird, ist die Datei fsimage selbst leer. Wann immer NameNode eine Anforderung zum Erstellen / Aktualisieren / Löschen erhält, wird diese Anforderung zuerst in der edits -Datei aufgezeichnet, damit die Dauerhaftigkeit in der Datei edits beibehalten wird. Außerdem wird eine speicherinterne Aktualisierung durchgeführt. Da alle Leseanforderungen aus dem speicherinternen Snapshot der Metadaten bereitgestellt werden.
Seine Hauptaufgabe besteht darin, das Namespace-Image regelmäßig mit dem Bearbeitungsprotokoll zu verbinden, um zu verhindern, dass das Bearbeitungsprotokoll zu groß wird.
Sie sehen also, dass die edits -Datei zu diesem Zeitpunkt immer noch außerhalb der Grenzen wächst. Wenn nun der NameNode neugestartet wird oder aus irgendeinem Grund heruntergefahren und wieder hochgefahren wird, hat er keine Speicherrepräsentation der Metadaten, also muss er die edits -Datei lesen und den Snapshot im Speicher neu erstellen, was eine Weile dauern kann auf der edits Dateigröße.
Da edits selbst ein WAL (Write Ahead Log) ist, müssen alle Ereignisse nacheinander geschrieben werden (nur anhängen). Es könnte keine Aktualisierungen in der Datei geben, um zufällige Festplattensuchvorgänge zu verhindern.
Um diesen Overhead zu vermeiden (oder edits Datei verwaltbar zu halten) wurde SecondaryNameNode eingeführt. Der einzige Zweck der SNN besteht darin, sicherzustellen, dass die edits -Datei nicht außerhalb der Grenzen wächst. SNN löst also standardmäßig einen Prozess namens checkpointing aus, wenn edits Datei 64 MB oder jede Stunde erreicht (was immer zuerst eintritt).
Das Überprüfen des Prozesses selbst ist einfach, die SNN teilt der NN mit, dass sie ihr aktuelles edits Protokoll erstellt und eine neue Editierdatei mit dem Namen edits.new erstellt. SNN kopiert dann die fsimage- und edits-Datei von NN und beginnt mit der Anwendung der Ereignisse In der Editierungsdatei zu der bereits vorhandenen fsimage-Datei (von NN) wird die neue fsimage-Datei nach Fertigstellung an NN zurückgeschickt, und das NN ersetzt das vorhandene fsimage durch das neue SNN und benennt das edits.new in% co_de um %. Das NN hat jetzt eine aktuelle Version von edits , auf die Ereignisse von der fsimage -Datei angewendet wurden.
Wenn also der NameNode nach Abschluss des Prüfpunkts neu gestartet wird, muss NameNode nur den edits in den Speicher laden und nur die aktuellen Aktualisierungen von fsimage log anwenden (die nach Abschluss des Prüfpunkts gefüllt wurden) um sicherzustellen, dass es die aktuelle Ansicht des Namespace hat, die effizienter ist.