[
https://issues.apache.org/jira/browse/HBASE-25549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17279239#comment-17279239
]
Bharath Vissapragada commented on HBASE-25549:
----------------------------------------------
Thanks for the jira. We run into this quite often. Any simple DDL against
gigantic tables creates these storm of region reopens and to make matters worse
the "alter" command times out and retries in the background. This creates
{{#regions * #retries}} region reopens and temporary RITs.
Did a quick look at the patch and I agree with [~esteban] that an unintentional
use of this new command might result in a weird state for the table.
Unfortunately the way the current code is structured, it is very difficult to
make that decision automatically. So perhaps better to make it a part of the
actual alter command itself and let the users force it (if needed) with a
warning on the console?
> A new hbase shell command: 'alter_lazy'
> ---------------------------------------
>
> Key: HBASE-25549
> URL: https://issues.apache.org/jira/browse/HBASE-25549
> Project: HBase
> Issue Type: Improvement
> Components: master, shell
> Affects Versions: 3.0.0-alpha-1
> Reporter: Zhuoyue Huang
> Assignee: Zhuoyue Huang
> Priority: Major
> Fix For: 3.0.0-alpha-1
>
>
> Under normal circumstances, modifying a table will cause all regions
> belonging to the table to enter RIT. Imagine the following two scenarios：
> # Someone entered the wrong configuration （e.g. negative
> 'hbase.busy.wait.multiplier.max' value） when altering the table, causing
> thousands of online regions to fail to open, leading to online accidents.
> # Modify the configuration of a table, but this modification is not urgent,
> the regions are not expected to enter RIT immediately.
> 'alter_lazy' is a new command to modify a table without reopening any online
> regions except those regions were assigned by other threads or split etc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
