anoopsjohn commented on a change in pull request #2113:
URL: https://github.com/apache/hbase/pull/2113#discussion_r460664425



##########
File path: 
hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/InitMetaProcedure.java
##########
@@ -71,7 +71,11 @@ private static void writeFsLayout(Path rootDir, 
Configuration conf) throws IOExc
     LOG.info("BOOTSTRAP: creating hbase:meta region");
     FileSystem fs = rootDir.getFileSystem(conf);
     Path tableDir = CommonFSUtils.getTableDir(rootDir, 
TableName.META_TABLE_NAME);
-    if (fs.exists(tableDir) && !fs.delete(tableDir, true)) {
+    boolean removeMeta = conf.getBoolean(HConstants.REMOVE_META_ON_RESTART,

Review comment:
       // Checking if meta needs initializing.
       status.setStatus("Initializing meta table if this is a new deploy");
       InitMetaProcedure initMetaProc = null;
       // Print out state of hbase:meta on startup; helps debugging.
       RegionState rs = this.assignmentManager.getRegionStates().
           getRegionState(RegionInfoBuilder.FIRST_META_REGIONINFO);
       LOG.info("hbase:meta {}", rs);
       if (rs != null && rs.isOffline()) {
         Optional<InitMetaProcedure> optProc = 
procedureExecutor.getProcedures().stream()
           .filter(p -> p instanceof InitMetaProcedure).map(o -> 
(InitMetaProcedure) o).findAny();
         initMetaProc = optProc.orElseGet(() -> {
           // schedule an init meta procedure if meta has not been deployed yet
           InitMetaProcedure temp = new InitMetaProcedure();
           procedureExecutor.submitProcedure(temp);
           return temp;
         });
       }
   So the checks we do see that META location is not there in zk and so it 
thinks its new deploy.  So here is what we need to tackle.
   In cloud redeploy case we will see a pattern where we will have a clusterId 
in the FS and not in zk. This can be used as an indicator? IMO we should find 
it (using this way or other) that its a redeploy on an existing datset and all 
these places, we need to consider that also to decide we need such bootstrap 
steps.
   We should not be doing that with a config way IMO.  Because then in cloud 
based deploy, what if the 1st time start fail and there is a need for this 
bootstrap cleaning of META FS dir?
   Even the other unknown server case also.  Lets identify clearly this 
redeploy case and act then only.
   Can we pls ave that discuss and conclude on a solution for that and then 
move forward?
   




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Reply via email to