Uh oh!
There was an error while loading. Please reload this page.
HBASE-27333 Abort RS when the hostname is different from master seen - #4732
Conversation
Apache-HBase
commented
Aug 26, 2022
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Aug 26, 2022
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Aug 26, 2022
🎊 +1 overall
This message was automatically generated. |
Apache9
commented
Aug 31, 2022
Mind explain a bit? What do you mean by opposite? |
sunhelly
commented
Sep 2, 2022
Thank, @Apache9 . The problem here is that the condition for whether using the servername seen from master or seen from local regionserver when they are different is opposite. It' a problem since branch-1. After line #1347 in HRegionServer, the servername of the regionserver is set to the name seen from master. But if when In short, when the hostname seen from local regionserver and master is different, the current behavior from the code should either restart the regionserver or use the local configed hostname, never the hostname seen from master. Correct me if I missed something. Thanks. |
Apache-HBase
commented
Sep 2, 2022
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Sep 2, 2022
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Sep 2, 2022
🎊 +1 overall
This message was automatically generated. |
apurtell
commented
Oct 6, 2022
I think we are good here @Apache9 ? Going to merge this tomorrow unless objection. |
Apache9
commented
Oct 7, 2022
This is introduced by https://issues.apache.org/jira/browse/HBASE-12954. It seemed that we wanted to solve the problem where a region server can not be accessed through the hostname which we bind to. From my understanding, the current logic seems reasonable. If we have configured the hostname to use, but it is different from what master seen us, then this should be a critical problem and we should abort the region server. If not, we just log it, and use the hostname seen by master as it is more likely to be accessed by others. Does anyone remember the reason why the code is like this? |
sunhelly
commented
Oct 10, 2022
Thanks, @Apache9 and @apurtell . After looking at HBASE-12954, I think we should abort the RS when the hostname from master seen is different from RS seen, regardless of whether the hostname has been configured by the RS. |
Apache-HBase
commented
Oct 10, 2022
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Oct 10, 2022
💔 -1 overall
This message was automatically generated. |
Apache-HBase
commented
Oct 10, 2022
💔 -1 overall
This message was automatically generated. |
apurtell
left a comment
There was a problem hiding this comment.
I don't recall why the code is like this.
Since this PR has changed, I've changed my review status to Request Changes. TestMasterUseIp and TestRegionServerUseIp failures might be related. Will approve once the tests are green, or failures are excluded as not related.
sunhelly
commented
Oct 11, 2022
Thanks @apurtell for the review, I'll dig more. |
sunhelly
commented
Nov 14, 2022
The UT failed after HBASE-27304#4713, @2005hithlj, can you take a look? |
2005hithlj
commented
Nov 15, 2022
@sunhelly |
sunhelly
commented
Nov 15, 2022
I tested locally, and they definitely failed, @2005hithlj . |
2005hithlj
commented
Nov 16, 2022
@sunhelly |
sunhelly
commented
Nov 17, 2022
@2005hithlj Good. |
@sunhelly In addition, if hbase.unsafe.regionserver.hostname/hbase.master.hostname is not null, even if hbase.server.useip.enabled is true, useThisHostnameInstead will work. If hbase.unsafe.regionserver.hostname/hbase.master.hostname is null, and hbase.server.useip.enabled is true, the Master and RegionServers info saved in meta and ZK are exposed to the client in the form of IP, which is the purpose of my PR(please see HBASE-27304 for details). This logic seems to be all right. |
Apache-HBase
commented
Jan 29, 2023
💔 -1 overall
This message was automatically generated. |
Apache-HBase
commented
Jan 29, 2023
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Jan 29, 2023
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Jan 29, 2023
🎊 +1 overall
This message was automatically generated. |
sunhelly
commented
Jan 29, 2023
Apache-HBase
commented
Jan 29, 2023
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Jan 29, 2023
🎊 +1 overall
This message was automatically generated. |
sunhelly
commented
Feb 16, 2023
sunhelly
commented
Mar 21, 2023
…pache#4732) Signed-off-by: Andrew Purtell <apurtell@apache.org>
No description provided.