ambari-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMBARI-18590) RegionServer Registration Checks Fail During Upgrade If rDNS is Not Enabled
Date Thu, 13 Oct 2016 21:36:20 GMT

    [ https://issues.apache.org/jira/browse/AMBARI-18590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15573251#comment-15573251
] 

Hudson commented on AMBARI-18590:
---------------------------------

SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #5797 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5797/])
AMBARI-18590 - RegionServer Registration Checks Fail During Upgrade If (jhurley: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=4140cc78a0153799938c2dbe3f80c11ab3be2e30])
* (edit) ambari-server/src/main/resources/common-services/HBASE/0.96.0.2.0/package/scripts/upgrade.py


> RegionServer Registration Checks Fail During Upgrade If rDNS is Not Enabled
> ---------------------------------------------------------------------------
>
>                 Key: AMBARI-18590
>                 URL: https://issues.apache.org/jira/browse/AMBARI-18590
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-agent
>    Affects Versions: 2.2.0
>            Reporter: Jonathan Hurley
>            Assignee: Jonathan Hurley
>            Priority: Blocker
>             Fix For: 2.5.0
>
>         Attachments: AMBARI-18590.patch
>
>
> During a rolling upgrade, the upgrade orchestration must wait for each RegionServer to
register with the HBase master before moving onto the next RS restart. This is a very asynchronous
process which may occur several minutes after the daemon has actually started. 
> We have a check now which uses {{hbase shell}} along with {{status 'simple'}} to determine
if the host has registered by looking for the hostname. 
> However, if reverse DNS is not enabled, then this could potentially be IP addresses.
As a result, the check would always fail during upgrades:
> The HBase status command we use is {{status simple}}, which returns like so:
> {noformat}
> active master:  10.0.0.8:16000 1475801031124
> 2 backup masters
>     10.0.0.10:16000 1475801061290
>     10.0.0.13:16000 1475801046018
> 2 live servers
>     10.0.0.5:16020 1475798271407
>         requestsPerSecond=0.0, numberOfOnlineRegions=2, usedHeapMB=159, maxHeapMB=7840,
numberOfStores=3, numberOfStorefiles=1, storefileUncompressedSizeMB=0, storefileSizeMB=0,
memstoreSizeMB=0, storefileIndexSizeMB=0, readRequestsCount=14, writeRequestsCount=1, rootIndexSizeKB=0,
totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0, totalCompactingKVs=14, currentCompactedKVs=14,
compactionProgressPct=1.0, coprocessors=[MultiRowMutationEndpoint, SecureBulkLoadEndpoint]
>     10.0.0.7:16020 1475872741297
>         requestsPerSecond=0.0, numberOfOnlineRegions=1, usedHeapMB=1002, maxHeapMB=7840,
numberOfStores=1, numberOfStorefiles=1, storefileUncompressedSizeMB=0, storefileSizeMB=0,
memstoreSizeMB=0, storefileIndexSizeMB=0, readRequestsCount=0, writeRequestsCount=0, rootIndexSizeKB=0,
totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0, totalCompactingKVs=0, currentCompactedKVs=0,
compactionProgressPct=NaN, coprocessors=[SecureBulkLoadEndpoint]
> 0 dead servers
> Aggregate load: 0, regions: 3
> {noformat}
> If this lookup fails for the hostname, we should also try by IP address.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message