junegunn commented on PR #6892:
URL: https://github.com/apache/hbase/pull/6892#issuecomment-2786786201
Thanks for the review.
> FWIW I do wonder if there's no significant value in configuring your
clusters this way because it will work basically the same as an unbatched table
modification (regions will be reopened as quickly as the HMaster can process
their reopen procedures).
We're expecting two benefits of using the option, even without backoff.
1. Reduce the number of regions that are (temporarily) unavailable at a
certain point during an alter operation (determined by the number of region
servers and their `hbase.regionserver.executor.closeregion.threads`) to achieve
better region availability and less overall service impact. For example, we can
set the option to something like 16 to ensure that at most 16 regions are
unavailable at a certain point. This helps in minimizing service disruption of
a latency sensitive application.
*
* `CLOSING` is when the region is marked `CLOSING` on `hbase:meta`
* `REJECT` is when the region actually becomes unavailable (client
starts getting `NotServingRegionException`)
*
* This plots the number of regions between `REJECT` and `OPEN` at a
certain point of time
*
*
1. It protects the table from a faulty alter operation as pointed out in
[HBASE-29136](https://issues.apache.org/jira/browse/HBASE-29136), because only
one region is affected.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
