Secondarynamenode the source analysis of the checkpoint process of Namenode

Secondarynamenode has two functions, one is mirrored backup, and the other is periodic merging of logs and mirrors. Two processes at the same time, called Checkpoint.

1. First analyze the Secondarynamenode creation process, the primary initialization logic in the Secondarynamenode.initialize (Configuration conf) method: 1.1) Get the parameters from the configuration file " Dfs.namenode.servicerpc-address "Value (is the address of the Namenode), if this address is empty, then get the value" dfs.namenode.rpc-address ", if it is still empty, then take" The value of Fs.default.name "as the default value;
1.2) According to the address obtained in the previous step through the "rpc.waitforproxy (...) "Create a Namenode object and assign a value to the Secondarynamenode.namenode variable;
1.3) Gets the parameter "Fs.checkpoint.dir" value (for the checkpoint directory), defaults to "/tmp/hadoop/dfs/namesecondary", initializes the file object to n directories, and assigns the value to the Secondarynamenode.checkpointdirs:collection<file> object;
1.4) Get the parameter "Fs.checkpoint.edits.dir" value (for checkpoint's edit file directory), default to "/tmp/hadoop/dfs/namesecondary", initialize the file object to n directories, and assigns the value to the Secondarynamenode.checkpointeditsdirs:collection<file> object;
1.5) "New Checkpointstorage ()" Initializes the Checkpointstorage object and assigns a value to the Secondarynamenode.checkpointimage variable, which inherits the Fsimage class;
1.6) "Checkpointstorage.recovercreate (collection<file> checkpointdirs, collection<file> Checkpointeditsdirs) ", set according to Checkpointdirs and Checkpointeditsdirs (Storage) Fsimage.storagedirs the value of the queue, the logic is the same as the second step in creating the Namenode. 3.2;
1.7) Get the parameters "Fs.checkpoint.period" and "fs.checkpoint.size", respectively, to indicate the size of the edit file for checkpoint period and checkpoint. ; Assign values to secondarynamenode.checkpointperiod and secondarynamenode.checkpointsize variables;

1.8) Initialize the Httpserver, assign a value to the Secondarynamenode.infoserver variable, and turn on this service: this service registers a Servlet:httpServer.addInternalServlet (" GetImage ","/getimage ", Getimageservlet.class, True, Securityutil.useksslauth ()); Register Getimageservlet;

The checkpoint flow of Secondarynamenode to Namenode is shown in the following figure:

The following is a detailed analysis of this process according to the source code:
2. Then analyze the logic of secondarynamenode processing checkpoint; in the Secondarynamenode run () method, call the DoWork () method to do the main work in a loop:
2.1) Call Namenode's Geteditlogsize () method via RPC, Namenode call Namesystem.geteditlogsize () method, internal call Fseditlog.geteditlogsize () Method calculates the size of the edit log;
2.2) If size is greater than the value of the parameter "Fs.checkpoint.size" in the configuration file (checkpoint) or the last detected time distance is now greater than the value of the parameter "Fs.checkpoint.period" in the configuration file, The Secondarynamenode.docheckpoint () method is executed:
2.2.1) Call the Startcheckpoint () method to initialize the working environment:
1) Unlock the ${fs.checkpoint.dir} and ${fs.checkpoint.edits.dir} paths;
2) close the FSEditLog.editStreams:EditLogOutputStream stream corresponding to the edit file;
3) "Checkpointimage.recovercreate (Checkpointdirs, Checkpointeditsdirs)": Set according to Checkpointdirs and CheckpointEditsDirs ( Storage) Fsimage.storagedirs The value of the queue and check the consistency of the files in all ${fs.checkpoint.dir} directories, as in the five. 2.4.2.2 steps in the creation of the namenode process;
4) "Checkpointimage.startcheckpoint ()" creates the current directory under the ${fs.checkpoint.dir} directory where, if ${fs.checkpoint.dir} A version file exists under the directory, You must ensure that the current file exists and cannot have a lastcheckpoint.tmp file, rename the current file to Lastcheckpoint.tmp, and then create the current directory, or create the current directory directly if there is no version file;
2.2.2) "Namenode.rolleditlog ()" Calls the Fsnamesystem.rolleditlog () method internally: Secondarynamenode notifies Namenode to commit the edits file, At this point in the main namenode node all ${dfs.name.dir} directory new Edits.new file, on the Namenode side of the specific steps are as follows:
1) Determine whether the Edits.new file exists, if it already exists, then return directly;
2) "Fsimage.restorestoragedirs ()" When initializing the Fsdirectory object on the Namenode side, reading the parameter "Dfs.namenode.name.dir.restore" indicates whether the deleted file is cached. The default is False, and if False, this method returns without any action, if true, and the Fsimage.removedstoragedirs:list<storagedirectory> collection is not empty. The Fsimage and edit files in current are restored to the storagedirectory specified directory in the Removedstoragedirs collection. The Storagedirectory object is removed from the Removedstoragedirs collection, and finally the Storagedirectory object is added to the storage.storagedirs;
3) Create a file object for the Edits.new. Editlogfileoutputstream object, and initialize it with the files object, and deposit fseditlog.editstreams:arraylist< Editlogoutputstream>; The subsequent operations log on the Namenode side will be recorded in the Edits.new file;
4) For an exception thrown during the initialization of the Editlogfileoutputstream object in the previous step, call "Fseditlog.removeeditsforstoragedir (storagedirectory SD)" First, If this throws an exception, the Editlogfileoutputstream object of the Storagedirectory object is in the Fseditlog.editstreams collection (comparing the path of the grandfather directory that corresponds to the Editstreams stream in the collection is associated with Storagedirector Y object is the same as the root path), then delete and then call "Fsimage.updateremoveddirs (storagedirectory SD)" Add this Storagedirectory object to the Removedstoragedirs collection;
2.2.3) "Secondarynamenode.downloadcheckpointfiles (checkpointsignature Sig)" Secondarynamenode via HTTP Get method to get Namenode fsimage and edits files, specifically implemented as follows:
Background: When Namenode is created, Httpserver.addinternalservlet is called in Namenode.starthttpserver (Configuration conf) ("GetImage", "/ GetImage ", Getimageservlet.class, True, Securityutil.useksslauth ()); Register Getimageservlet ; for Secondarynamenode to obtain fsimage and edit files from Namenode;
1) Get the file object for writing to fsimage files via SecondaryNameNode.checkpointImage.getImageFiles () ; Gets the file object used to write edits files through SecondaryNameNode.checkpointImage.getEditsFiles (), two files in Secondarynamenode ${ Fs.checkpoint.dir}/current and ${fs.checkpoint.edits.dir}/current directories;
2) "Transferfsimage.getfileclient (string fsname, String ID, file[] localPath, Boolean getchecksum)" Secondarynamenode gets fsimage and edits files to Namenode by HTTP GET, and writes them to the two file objects respectively;
2.2.4) "Secondarynamenode.domerge (checkpointsignature Sig)" Secondarynamenode began merging Namenode and edit files obtained from Fsimage, Generate an up-to-date directory tree structure in memory and generate a new Fsimage file in the ${fs.checkpoint.dir}/previous.checkpoint directory:
1) Invoke the Fsimage.loadfsimage (file Curfile) method to load the Fsimage file;
2) Call Fsimage.loadfsedits (storagedirectory sd,metarecoverycontext Recovery) method, call Fseditlog.loadfsedits internally ( Editloginputstream edits, int
Tolerationlength, metarecoverycontext recovery) load the contents of the edits file, in fact, in this method will be the operation of the log records re-execution, so that the combination of operations to add to the directory tree structure;
3) "Fsimage.savenamespace (Boolean Renewcheckpointtime=false)" survives a new Fsimage file based on the directory tree structure that was generated in memory in the previous two steps, with the following specific logic:
A) Call the Fsimage.movecurrent (storagedirectory sd) method, move the contents of the current directory to lastcheckpoint.tmp, and recreate the current directory;
b) Call the Fsimage.savecurrent (storagedirectory sd) method to write the in-memory directory tree structure to the Fsimage file in the current directory, and internally call Fsimage.savefsimage (file NewFile) method;
c) Call the Fsimage.savecurrent (storagedirectory SD) method to create an empty edits file;
d) Call Fsimage.movelastcheckpoint (Storagedirectory SD) to move the contents of the Lastcheckpoint.tmp directory in step A to the Previous.checkpoint directory;
2.2.5) "Secondarynamenode.putfsimage (Checkpointsignature sig)", Function: Secondarynamenode notifies namenode that the new Fsimage file generated in the 2nd 2.4 step can be obtained from Secondarynamenode on HTTP GET.
1) Call Transferfsimage.getfileclient (String fsname,string ID, file[] localPath, Boolean getchecksum) Method notifies the main namenode to obtain the latest Fsimage file from Secondarynamenode, which sends Secondarynamenode Machine/port and other information to the main namenode;
2) The main namenode check to Secondarynamenode request parameter is Putimage, then use this information and secondarynamenode to establish an HTTP connection, obtain fsimage information;
3) The Master Namenode obtains the latest Fsimage file, generates the Fsimage.ckpt file;
Note: The communication between Namenode and secondary namenode data, using the HTTP protocol, the HTTP container is Jetty,transferfsimage is the auxiliary class for file transfer. Have registered a servlet container getimageservlet;secondary namenode send an HTTP request to Namenode, start Namenode Previous HTTP client to secondary Namenode up to download fsimage, download the required information, all in the HTTP request to Namenode.
2.2.6) "Namenode.rollfsimage ()" Internal call Process Fsnamesystem.rollfsimage ()--->fsimage.rollfsimage ()
1) Check the Namenode side of the Edits.new file exists, does not exist and throws an exception;
2) Check the existence of fsimage.ckpt file in each ${dfs.name.dir}/current directory, and throw exception if not present;
3) "Editlog.purgeeditlog ()", rename the Edits.new file under each ${dfs.name.dir}/current directory to edits:
A) Rename the edits.new file to edits, delete the edits file, and delete the Storagedirectory object from the Storage.storagedirs;
b) Delete the output stream of the old edits file from the Fseditlog.editstreams and reopen the output stream of the new edits file;
4) Rename the Fsimage.ckpt file to Fsimage and delete the current Fsimage file, and delete the Storagedirectory object from the Storage.storagedirs;
5) If there are still storagedirectory objects in the storage.storagedirs that are considered to be old fsimage and edits files, delete these files;
2.2.7) "Checkpointimage.endcheckpoint ()" Moves the contents of the Lastcheckpoint.tmp directory under the path of all Storagedirectory objects stored in the Storage.storagedirs to the Previous.checkpoint directory; This operation was performed in 2nd. 2.4, and why a It's all over.
2.3) After the completion of step 2.2, update secondarynamenode.lastcheckpointtime, that is, the most recent checkpoint time;
2.4) The Secondarynamenode execution of the checkpoint operation is completed, the subsequent periodic implementation of steps 2.1 to 2.3 for checkpoint inspection;