用于高可用性的 Hadoop 2.0 名称节点、辅助节点和检查点节点
Hadoop 2.0 Name Node, Secondary Node and Checkpoint node for High Availability
读完Apache Hadoop documentation ，对secondary node & check point node的职责理解有点混乱
我很清楚 Namenode 的角色和职责：
- The NameNode stores modifications to the file system as a log appended to a native file system file, edits. When a NameNode starts up, it reads HDFS state from an image file, fsimage, and then applies edits from the edits log file. It then writes new HDFS state to the fsimage and starts normal operation with an empty edits file. Since NameNode merges fsimage and edits files only during start up, the edits log file could get very large over time on a busy cluster. Another side effect of a larger edits file is that next restart of NameNode takes longer.
但是我在理解辅助名称节点和检查点名称节点职责时有点困惑。
辅助 NameNode:
- The secondary NameNode merges the fsimage and the edits log files periodically and keeps edits log size within a limit. It is usually run on a different machine than the primary NameNode since its memory requirements are on the same order as the primary NameNode.
检查点节点：
- The Checkpoint node periodically creates checkpoints of the namespace. It downloads fsimage and edits from the active NameNode, merges them locally, and uploads the new image back to the active NameNode. The Checkpoint node usually runs on a different machine than the NameNode since its memory requirements are on the same order as the NameNode. The Checkpoint node is started by bin/hdfs namenode -checkpoint on the node specified in the configuration file.
似乎Secondary namenode和Checkpoint节点之间的职责不明确。两者都在进行编辑。那么最后谁来修改呢？
另一方面，我在 jira 中创建了两个错误，以消除理解这些概念时的歧义。
issues.apache.org/jira/browse/HDFS-8913
issues.apache.org/jira/browse/HDFS-8914
NameNode（主节点）
NameNode存储HDFS的元数据。 HDFS 的状态存储在一个名为 fsimage 的文件中，它是元数据的基础。在运行时修改只是写入一个名为 edits 的日志文件。在 NameNode 的下一次启动时，状态从 fsimage 读取，编辑的更改应用于它，新状态写回 fsimage。清除此编辑并包含现在准备好新的日志条目后。
检查点节点
Checkpoint Node的引入解决了NameNode的弊端。更改仅写入编辑，不会在运行时合并到 fsimage。如果 NameNode 运行一段时间，编辑会变得很大，下一次启动将花费更长的时间，因为必须对状态应用更多更改以确定元数据的最后状态。
Checkpoint Node定期从NameNode中获取fsimage和edits并合并。结果状态称为检查点。然后将结果上传到NameNode。
还有一种名为“Secondary Node”的类似节点，但它没有“上传到 NameNode”功能。所以 NameNode 需要从 Secondary NameNode 获取状态。这也令人困惑，因为名称暗示如果 NameNode 失败，则辅助 NameNode 接受请求，但事实并非如此。
备份节点
备份节点提供与检查点节点相同的功能，但与名称节点同步。它不需要定期获取更改，因为它会收到一系列文件系统编辑。来自 NameNode。它在内存中保存当前状态，只需要将其保存到图像文件中即可创建新的检查点。
NameNode- 也称为主节点。 Namenode 存储元数据，即块数、它们的位置、副本和其他详细信息。此元数据在主机的内存中可用，以便更快地检索数据。 NameNode维护和管理从节点，并为它们分配任务。它应该部署在可靠的硬件上，因为它是 HDFS 的核心。 Namenode 使用如下两个文件保存其命名空间：
FsImage: FsImage 是一个“图像文件”。它包含整个文件系统命名空间，并作为文件存储在名称节点的本地文件系统中。
EditLogs：它包含最近对文件系统所做的关于最新 FsImage 的所有修改。
Checkpoint节点- Checkpoint节点是周期性创建namespace的checkpoints的节点。 Hadoop 中的 Checkpoint Node 首先从活动的 Namenode 下载 fsimage 和 edits。然后它在本地合并它们（FsImage 和编辑），最后它将新图像上传回活动的 NameNode。检查点节点将最新的检查点存储在一个目录中。它的结构与 Namenode 的目录相同。它允许检查点图像可供名称节点读取。
备份节点-备份节点提供与检查点节点相同的检查点功能。在 Hadoop 中，备份节点在内存中保留文件系统命名空间的最新副本，该副本始终与活动的 NameNode 状态同步。 Backup 节点不需要从活动 NameNode 下载 fsimage 和编辑文件来创建检查点，就像 Checkpoint 节点或 Secondary Namenode 所需要的那样，因为它已经具有命名空间状态的最新状态在记忆中。备份节点检查点过程更高效，因为它只需要将命名空间保存到本地 fsimage 文件并重置编辑。 NameNode 一次支持一个 Backup 节点。如果正在使用备份节点，则不能注册任何检查点节点。
读完Apache Hadoop documentation ，对secondary node & check point node的职责理解有点混乱
我很清楚 Namenode 的角色和职责：
- The NameNode stores modifications to the file system as a log appended to a native file system file, edits. When a NameNode starts up, it reads HDFS state from an image file, fsimage, and then applies edits from the edits log file. It then writes new HDFS state to the fsimage and starts normal operation with an empty edits file. Since NameNode merges fsimage and edits files only during start up, the edits log file could get very large over time on a busy cluster. Another side effect of a larger edits file is that next restart of NameNode takes longer.
但是我在理解辅助名称节点和检查点名称节点职责时有点困惑。
辅助 NameNode:
- The secondary NameNode merges the fsimage and the edits log files periodically and keeps edits log size within a limit. It is usually run on a different machine than the primary NameNode since its memory requirements are on the same order as the primary NameNode.
检查点节点：
- The Checkpoint node periodically creates checkpoints of the namespace. It downloads fsimage and edits from the active NameNode, merges them locally, and uploads the new image back to the active NameNode. The Checkpoint node usually runs on a different machine than the NameNode since its memory requirements are on the same order as the NameNode. The Checkpoint node is started by bin/hdfs namenode -checkpoint on the node specified in the configuration file.
似乎Secondary namenode和Checkpoint节点之间的职责不明确。两者都在进行编辑。那么最后谁来修改呢？
另一方面，我在 jira 中创建了两个错误，以消除理解这些概念时的歧义。
issues.apache.org/jira/browse/HDFS-8913
issues.apache.org/jira/browse/HDFS-8914
NameNode（主节点）
NameNode存储HDFS的元数据。 HDFS 的状态存储在一个名为 fsimage 的文件中，它是元数据的基础。在运行时修改只是写入一个名为 edits 的日志文件。在 NameNode 的下一次启动时，状态从 fsimage 读取，编辑的更改应用于它，新状态写回 fsimage。清除此编辑并包含现在准备好新的日志条目后。
检查点节点
Checkpoint Node的引入解决了NameNode的弊端。更改仅写入编辑，不会在运行时合并到 fsimage。如果 NameNode 运行一段时间，编辑会变得很大，下一次启动将花费更长的时间，因为必须对状态应用更多更改以确定元数据的最后状态。
Checkpoint Node定期从NameNode中获取fsimage和edits并合并。结果状态称为检查点。然后将结果上传到NameNode。
还有一种名为“Secondary Node”的类似节点，但它没有“上传到 NameNode”功能。所以 NameNode 需要从 Secondary NameNode 获取状态。这也令人困惑，因为名称暗示如果 NameNode 失败，则辅助 NameNode 接受请求，但事实并非如此。
备份节点
备份节点提供与检查点节点相同的功能，但与名称节点同步。它不需要定期获取更改，因为它会收到一系列文件系统编辑。来自 NameNode。它在内存中保存当前状态，只需要将其保存到图像文件中即可创建新的检查点。
NameNode- 也称为主节点。 Namenode 存储元数据，即块数、它们的位置、副本和其他详细信息。此元数据在主机的内存中可用，以便更快地检索数据。 NameNode维护和管理从节点，并为它们分配任务。它应该部署在可靠的硬件上，因为它是 HDFS 的核心。 Namenode 使用如下两个文件保存其命名空间：
FsImage: FsImage 是一个“图像文件”。它包含整个文件系统命名空间，并作为文件存储在名称节点的本地文件系统中。
EditLogs：它包含最近对文件系统所做的关于最新 FsImage 的所有修改。
Checkpoint节点- Checkpoint节点是周期性创建namespace的checkpoints的节点。 Hadoop 中的 Checkpoint Node 首先从活动的 Namenode 下载 fsimage 和 edits。然后它在本地合并它们（FsImage 和编辑），最后它将新图像上传回活动的 NameNode。检查点节点将最新的检查点存储在一个目录中。它的结构与 Namenode 的目录相同。它允许检查点图像可供名称节点读取。
备份节点-备份节点提供与检查点节点相同的检查点功能。在 Hadoop 中，备份节点在内存中保留文件系统命名空间的最新副本，该副本始终与活动的 NameNode 状态同步。 Backup 节点不需要从活动 NameNode 下载 fsimage 和编辑文件来创建检查点，就像 Checkpoint 节点或 Secondary Namenode 所需要的那样，因为它已经具有命名空间状态的最新状态在记忆中。备份节点检查点过程更高效，因为它只需要将命名空间保存到本地 fsimage 文件并重置编辑。 NameNode 一次支持一个 Backup 节点。如果正在使用备份节点，则不能注册任何检查点节点。