[
https://issues.apache.org/jira/browse/HDFS-17137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17751462#comment-17751462
]
ASF GitHub Bot commented on HDFS-17137:
---------------------------------------
Hexiaoqiao commented on code in PR #5913:
URL: https://github.com/apache/hadoop/pull/5913#discussion_r1285409083
##########
hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/ha/TestStandbyBlockManagement.java:
##########
@@ -97,4 +97,58 @@ public void testInvalidateBlock() throws Exception {
}
}
+ /**
+ * Test Standby/Observer NameNode should not handle redundant replica block
logic
+ * when set decrease replication.
+ * @throws Exception
+ */
+ @Test(timeout = 60000)
+ public void testNotHandleRedundantReplica() throws Exception {
+ Configuration conf = new Configuration();
+ HAUtil.setAllowStandbyReads(conf, true);
+ conf.setInt(DFSConfigKeys.DFS_HA_TAILEDITS_PERIOD_KEY, 1);
+
+ // Create HA Cluster.
+ try (MiniDFSCluster cluster = new MiniDFSCluster.Builder(conf)
+
.nnTopology(MiniDFSNNTopology.simpleHATopology()).numDataNodes(10).build()) {
Review Comment:
Here num of DataNode is 10, is it necessary? I think it is enough to set 4,
what do you think about?
##########
hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/namenode/ha/TestStandbyBlockManagement.java:
##########
@@ -97,4 +97,58 @@ public void testInvalidateBlock() throws Exception {
}
}
+ /**
+ * Test Standby/Observer NameNode should not handle redundant replica block
logic
+ * when set decrease replication.
+ * @throws Exception
+ */
+ @Test(timeout = 60000)
+ public void testNotHandleRedundantReplica() throws Exception {
+ Configuration conf = new Configuration();
+ HAUtil.setAllowStandbyReads(conf, true);
+ conf.setInt(DFSConfigKeys.DFS_HA_TAILEDITS_PERIOD_KEY, 1);
+
+ // Create HA Cluster.
+ try (MiniDFSCluster cluster = new MiniDFSCluster.Builder(conf)
+
.nnTopology(MiniDFSNNTopology.simpleHATopology()).numDataNodes(10).build()) {
+ cluster.waitActive();
+ cluster.transitionToActive(0);
+
+ NameNode nn1 = cluster.getNameNode(0);
+ assertEquals("ACTIVE", nn1.getNamesystem().getState().name());
+ NameNode nn2 = cluster.getNameNode(1);
+ assertEquals("STANDBY", nn2.getNamesystem().getState().name());
+
+ cluster.triggerHeartbeats();
+ // Sending the FBR.
+ cluster.triggerBlockReports();
+
+ // Default excessRedundancyMap size as 0.
+ assertEquals(0,
nn1.getNamesystem().getBlockManager().getExcessBlocksCount());
+ assertEquals(0,
nn2.getNamesystem().getBlockManager().getExcessBlocksCount());
+
+ FileSystem fs = HATestUtil.configureFailoverFs(cluster, conf);
+
+ // Create test file.
+ Path file = new Path("/test");
+ long fileLength = 512;
+ DFSTestUtil.createFile(fs, file, fileLength, (short) 8, 0L);
Review Comment:
Here set the replication to 4 is enough?
> Standby/Observer NameNode should not handle redundant replica block logic
> when set decrease replication
> ----------------------------------------------------------------------------------------------------------
>
> Key: HDFS-17137
> URL: https://issues.apache.org/jira/browse/HDFS-17137
> Project: Hadoop HDFS
> Issue Type: Improvement
> Reporter: Haiyang Hu
> Assignee: Haiyang Hu
> Priority: Major
> Labels: pull-request-available
>
> Standby/Observer NameNode should not handle redundant replica block logic
> when set decrease replication.
> At present, when call setReplication to execute the logic of decrease
> replication,
> * ActiveNameNode will call the BlockManager#processExtraRedundancyBlock
> method to select the dn of the redundant replica , will add to the
> excessRedundancyMap and add to invalidateBlocks (RedundancyMonitor will be
> scheduled to delete the block on dn).
> * Then the StandyNameNode or ObserverNameNode load editlog and apply the
> SetReplicationOp, if the dn of the replica to be deleted has not yet
> performed incremental block report,
> here also will BlockManager#processExtraRedundancyBlock method be called here
> to select the dn of the redundant replica and add it to the
> excessRedundancyMap (here selected the redundant dn may be inconsistent with
> the dn selected in the active namenode).
> In excessRedundancyMap exist dn maybe affects the dn decommission, resulting
> can not to complete decommission dn operation in Standy/ObserverNameNode.
> The specific cases are as follows:
> For example a file is 3 replica (d1,d2,d3) and call setReplication set file
> to 2 replica.
> * ActiveNameNode select d1 with redundant replicas to add
> toexcessRedundancyMap and invalidateBlocks.
> * StandyNameNode replays SetReplicationOp (at this time, d1 has not yet
> executed incremental block report), so here maybe selected redundant replica
> dn are inconsistent with ActiveNameNode, such as select d2 to add
> excessRedundancyMap.
> * At this time, d1 completes deleting the block for incremental block report.
> * The DN list for this block in ActiveNameNode includes d2 and d3 (delete d1
> from in the excessRedundancyMap when processing the incremental block report
> ).
> * The DN list for this block in StandyNameNode includes d2 and d3 (can not
> delete d2 from in the excessRedundancyMap when processing the incremental
> block report).
> At this time, execute the decommission operation on d3.
> * ActiveNameNode will select a new node d4 to copy the replica, and d4 will
> run incrementally block report.
> * The DN list for this block in ActiveNameNode includes d2 and
> d3(decommissioning status),d4, then d3 can to decommissioned normally.
> * The DN list for this block in StandyNameNode is d3 (decommissioning
> status), d2 (redundant status), d4.
> since the requirements for two live replica are not met, d3 cannot be
> decommissioned at this time.
> Therefore, StandyNameNode or ObserverNameNode considers not process redundant
> replicas logic when call setReplication.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
