immagine dello spazio dei nomi e modificare il login

Question

Dal libro "Hadoop The Definitive Guide", sotto il tema Namenodes e Datanodes si è detto che:

NameNode gestisce lo spazio dei nomi file system. Mantiene la struttura del file system e i metadati per tutti i file e le directory nella struttura dell'albero. Queste informazioni sono memorizzate in modo persistente sul disco locale in sotto forma di due file: l'immagine dello spazio dei nomi e il registro di modifica.

namenode secondario, che nonostante il suo nome non funge da un namenode. Il suo ruolo principale consiste nel unire periodicamente l'immagine dello spazio dei nomi con il registro di modifica per impedire che il registro di modifica diventi troppo grande.

Sto avendo un po 'di confusione con questi file namespace e Registro modifiche.

L'immagine dello spazio dei nomi è per la memorizzazione dei metadati.

Quindi, le mie domande sono

1. Qual è il registro modifica? E qual è il suo ruolo?
2. Puoi spiegare la frase "Il suo ruolo principale è unire periodicamente l'immagine dello spazio dei nomi con il registro di modifica per evitare che il registro di modifica diventi troppo grande."?

Answer 1

Per favore qualcuno può spiegarmi qual è il registro di modifica? Qual è il ruolo di questo file di registro?

Inizialmente all'avvio del NameNode, il file fsimage sarà vuoto. Quando mai NameNode riceve una richiesta di creazione/aggiornamento/cancellazione, quella richiesta viene prima registrata nel file edits per la sua durata una volta persistente nel file edits e viene anche effettuato un aggiornamento in memoria. Perché tutte le richieste di lettura sono fornite da un'istantanea in memoria dei metadati.

Il suo ruolo principale consiste nel fondere periodicamente l'immagine dello spazio dei nomi con il registro di modifica per impedire che il registro di modifica diventi troppo grande.

Quindi, a questo punto, il file edits continua a crescere senza limiti. Ora se il NameNode viene riavviato o per qualche motivo è andato giù e riportato in su, non ha alcuna rappresentazione della memoria dei metadati, quindi deve leggere il file edits e ricostruire l'istantanea in memoria, che potrebbe richiedere un po 'in base al Dimensione del file edits.

Poiché edits è di per sé un WAL (registro di scrittura in anticipo), tutti gli eventi devono essere scritti uno dopo l'altro (append solo), non ci sono aggiornamenti nel file per impedire la ricerca casuale di dischi.

Per impedire questo sovraccarico (o per mantenere gestibile il file edits) è stato introdotto SecondaryNameNode.L'unico scopo del SNN è quello di assicurarsi che il file edits non cresca oltre i limiti. Quindi, per impostazione predefinita, SNN attiva un processo chiamato come checkpointing quando il file edits raggiunge 64 MB o ogni ora (che viene sempre prima).

processo di Checkpoint è di per sé è semplice, lo SNN dice al NN al ruolo di suo attuale registro edits e creare un nuovo file Modifiche chiamati edits.new, SNN quindi copia sopra il fsimage e modifica file da NN e si avvia l'applicazione gli eventi nelle modifiche file su file fsimage già esistente (portato da NN), una volta completato il nuovo file fsimage viene rinviato a NN e l'NN sostituisce il file fsimage esistente con quello nuovo inviato da SNN e rinomina lo edits.new in edits. L'NN ora ha una versione corrente di fsimage che ha eventi applicati dal file edits.

Quindi, che se il NameNode viene riavviato dopo checkpoint è stato completato, NameNode deve caricare solo il fsimage alla memoria e applicare solo gli aggiornamenti recents da edits registro (che si è riempito dopo il checkpoint è stato completato) per assicurarsi ha la vista aggiornata dello spazio dei nomi che è più efficiente.