8 Image/edits file retention policies 10
9 Future Directions 10
9.1 NN-triggered checkpointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.2 Offline Checkpointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.3 Shared storage for metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10 Test Plan 11
10.1 Existing Unit Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1.1 TestCheckpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1.2 TestBackupNode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.2 New Unit Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.2.1 TestEditLogRecovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.3 BackupNode Stress Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1 Transaction IDs
HDFS has had the concept of a transaction ID used inside FSEditLog for a long time. Transaction IDs
are assigned sequentially to threads as they write data into the log. They are then used to facilitate group
commit during logSync().
1.1 Persistent Transaction IDs
One of the subtasks of HDFS-1073 is HDFS-1521, which makes the transaction IDs persist across restarts of
the NameNode. That is to say, the first edit on a newly formatted NN will have transaction ID 1, and that
ID will never be reused for the lifetime of the namesystem (even after restarts and checkpoints).
1.2 Non-namespace transactions
FSEditLog already contains a couple of special transactions which do not correspond to actual modifications
of the filesystem namespace, but instead are used to inform the BackupNode when the primary NameNode’s
logs are rolled, etc. We plan to add the following special transactions:
1. OP BEGIN LOG SEGMENT - this transaction is written at the start of every new edit log file. It currently
contains no data, but may later contain some special checkpointing information or metadata about the
namespace.
2. OP END LOG SEGMENT - this transaction is written at the end of an edit log before it is closed. This is
used as a sanity check that the log was gracefully closed, and is also useful to allow the BackupNode
to synchronize its log roll with the primary NameNode. In the future it might be extended to include
some kind of checksum information about the log file.
These two special transactions also serve another purpose: they ensure that all edit logs contain at least
one transaction. This avoids having to add many special case code-paths for empty edits files.
2
评论0
最新资源