Apache9 commented on pull request #2113:
URL: https://github.com/apache/hbase/pull/2113#issuecomment-663328123
In general, if you touch the internal of HBase directly, it may lead to data
loss, unexpected behavior, etc.
As I said above, the current design is to compare the WAL
Apache9 commented on pull request #2113:
URL: https://github.com/apache/hbase/pull/2113#issuecomment-663325543
> In this scenario, regardless of what we do, there will be dataloss unless
the correct WAL directory is (again) specified. In fact, I don't believe you
can change WAL dir
Apache9 commented on pull request #2113:
URL: https://github.com/apache/hbase/pull/2113#issuecomment-662876047
> You're right that the new set of region servers start on new environment
that they are identified as 'Unknown server'.
I think the old server will be unknown servers, not
Apache9 commented on pull request #2113:
URL: https://github.com/apache/hbase/pull/2113#issuecomment-662859269
OK, just saw this on jira
> They were in a separate WAL directory. The assumption here is that all the
data has been flushed and there is no data needing to be replayed
Apache9 commented on pull request #2113:
URL: https://github.com/apache/hbase/pull/2113#issuecomment-662844100
I haven't gotten the point of 'Unknown Servers' here.
When setting up a region server, we will create a WAL directory for it. And
when restarting master, we will pull the
Apache9 commented on pull request #2113:
URL: https://github.com/apache/hbase/pull/2113#issuecomment-662787462
I haven't looked at the patch yet, but what I want to say is that, it is not
a good idea to use HBCK stuff in automatic fail recovery. The design of HBCK is
that, the operation
