[
https://issues.apache.org/jira/browse/HBASE-29970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiao Liu updated HBASE-29970:
-----------------------------
Description:
This change removes the unused {{{}incrSplitSuccess(){}}},
{{{}updateSplitTime(){}}}, and related split success/time metrics from
RegionServer and Table level metrics sources.
These metrics {{splitSuccess}} and {{splitTime}} is introduced by HBASE-12779,
the split operation has been migrated from RegionServer-driven local execution
to Master-driven Procedure-based coordination. When a RegionServer triggers a
split due to region size threshold, it only sends a {{READY_TO_SPLIT}} state
transition request to the Master via {{{}reportRegionStateTransition(){}}}. The
Master then creates a {{SplitTableRegionProcedure}} to asynchronously
coordinate the entire split process. The RegionServer has no knowledge of when
(or whether) the split completes successfully, so it cannot update split
success or timing metrics, in HBASE-16549 we refactor split metric logic and
start to use {{splitProcMetrics}} tracking the split behaivor
h3. Current Behavior
* Split request metrics ({{{}splitRequestCount{}}}) are properly updated when
a split is initiated (RS level)
* Split success/time metrics at RegionServer and Table level were defined but
never called
* Master-side split metrics ({{{}splitSubmittedCount{}}}, {{{}splitTime{}}},
{{{}splitFailedCount{}}}) are correctly maintained via the Procedure
framework's {{getProcedureMetrics()}} mechanism
h3. Changes Made
* Removed {{incrSplitSuccess()}} and {{updateSplitTime()}} methods from
{{MetricsRegionServerSource}} and {{{}MetricsRegionServerSourceImpl{}}},
corresponding methods from {{MetricsTableSource}} and
{{{}MetricsTableSourceImpl{}}}, and related metric definitions and histogram
variables
* We keep {{SplitRequest}} and support table-level updates for this metic to
track split caused by region size exceeds the configured max size
{code:java}
CompactSplit.requestSplit()
→ new SplitRequest(r, midKey, server, user)
→ splits.execute(splitRequest)
→ SplitRequest.run()
→ doSplitting()
→ server.getMetrics().incrSplitRequest(tableName)
{code}
was:
This change removes the unused \{{incrSplitSuccess()}}, \{{updateSplitTime()}},
and related split success/time metrics from RegionServer and Table level
metrics sources.
These metrics \{{splitSuccess}} and \{{splitTime}} is introduced by
HBASE-12779, the split operation has been migrated from RegionServer-driven
local execution to Master-driven Procedure-based coordination. When a
RegionServer triggers a split due to region size threshold, it only sends a
\{{READY_TO_SPLIT}} state transition request to the Master via
\{{reportRegionStateTransition()}}. The Master then creates a
\{{SplitTableRegionProcedure}} to asynchronously coordinate the entire split
process. The RegionServer has no knowledge of when (or whether) the split
completes successfully, so it cannot update split success or timing metrics, in
HBASE-16549 we refactor split metric logic and start to use
\{{splitProcMetrics}} tracking the split behaivor
h3. Current Behavior
* Split request metrics (\{{splitRequestCount}}) are properly updated when a
split is initiated
* Split success/time metrics at RegionServer and Table level were defined but
never called
* Master-side split metrics (\{{splitSubmittedCount}}, \{{splitTime}},
\{{splitFailedCount}}) are correctly maintained via the Procedure framework's
\{{getProcedureMetrics()}} mechanism
h3. Changes Made
* Removed \{{incrSplitSuccess()}} and \{{updateSplitTime()}} methods from
\{{MetricsRegionServerSource}} and \{{MetricsRegionServerSourceImpl}},
corresponding methods from \{{MetricsTableSource}} and
\{{MetricsTableSourceImpl}}, and related metric definitions and histogram
variables
* We keep \{{SplitRequest}} and support table-level updates for this metic to
track split caused by region size exceeds the configured max size
{code:language=bash|borderStyle=solid|theme=RDark|linenumbers=true|collapse=false}
CompactSplit.requestSplit()
→ new SplitRequest(r, midKey, server, user)
→ splits.execute(splitRequest)
→ SplitRequest.run()
→ doSplitting()
→ server.getMetrics().incrSplitRequest(tableName)
{code}
> SplitSuccess and SplitTime metrics are no longer used at RegionServer and
> Table level
> -------------------------------------------------------------------------------------
>
> Key: HBASE-29970
> URL: https://issues.apache.org/jira/browse/HBASE-29970
> Project: HBase
> Issue Type: Improvement
> Components: metrics
> Reporter: Xiao Liu
> Assignee: Xiao Liu
> Priority: Major
> Labels: pull-request-available
> Fix For: 2.7.0, 3.0.0-beta-2, 2.6.5, 2.5.14
>
>
> This change removes the unused {{{}incrSplitSuccess(){}}},
> {{{}updateSplitTime(){}}}, and related split success/time metrics from
> RegionServer and Table level metrics sources.
> These metrics {{splitSuccess}} and {{splitTime}} is introduced by
> HBASE-12779, the split operation has been migrated from RegionServer-driven
> local execution to Master-driven Procedure-based coordination. When a
> RegionServer triggers a split due to region size threshold, it only sends a
> {{READY_TO_SPLIT}} state transition request to the Master via
> {{{}reportRegionStateTransition(){}}}. The Master then creates a
> {{SplitTableRegionProcedure}} to asynchronously coordinate the entire split
> process. The RegionServer has no knowledge of when (or whether) the split
> completes successfully, so it cannot update split success or timing metrics,
> in HBASE-16549 we refactor split metric logic and start to use
> {{splitProcMetrics}} tracking the split behaivor
> h3. Current Behavior
> * Split request metrics ({{{}splitRequestCount{}}}) are properly updated
> when a split is initiated (RS level)
> * Split success/time metrics at RegionServer and Table level were defined
> but never called
> * Master-side split metrics ({{{}splitSubmittedCount{}}}, {{{}splitTime{}}},
> {{{}splitFailedCount{}}}) are correctly maintained via the Procedure
> framework's {{getProcedureMetrics()}} mechanism
> h3. Changes Made
> * Removed {{incrSplitSuccess()}} and {{updateSplitTime()}} methods from
> {{MetricsRegionServerSource}} and {{{}MetricsRegionServerSourceImpl{}}},
> corresponding methods from {{MetricsTableSource}} and
> {{{}MetricsTableSourceImpl{}}}, and related metric definitions and histogram
> variables
> * We keep {{SplitRequest}} and support table-level updates for this metic to
> track split caused by region size exceeds the configured max size
> {code:java}
> CompactSplit.requestSplit()
> → new SplitRequest(r, midKey, server, user)
> → splits.execute(splitRequest)
> → SplitRequest.run()
> → doSplitting()
> → server.getMetrics().incrSplitRequest(tableName)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
