Re: Introduce a new annotation to say there is no BC guarantee in the inheritance

Sorry to dig up this old thread. I've also just commented on < https://issues.apache.org/jira/browse/HBASE-19746> The book says: > MAJOR version when you make incompatible API changes, So do we really need to keep BC between major versions? How else would we ever add new methods to interfaces

[jira] [Resolved] (HBASE-20459) Majority of scan CPU time in HBase-1 spent in size estimation

[ https://issues.apache.org/jira/browse/HBASE-20459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-20459. --- Resolution: Fixed Pushed to branch-2 and branch-2.0. Re-resolving. > Majority of scan CPU time in HBase-1

Re: Tools for balancing a poorly distributed table

For #2, currently SimpleRegionNormalizer only takes into account region sizes. Meaning, even if the regions under consideration are receiving heavy read / write requests, the regions may still be chosen to be split / merged. It seems the normalizer should also consider read / write requests so

Re: Tools for balancing a poorly distributed table

Thanks Tim! I've seen both problems myself (independent of Tim I should add, even though he helps us here) and continue to see them at customers almost every month. 1) Hard to determine proper pre-split points: Everyone I meet either just guesses or writes their own little program that basically

[jira] [Reopened] (HBASE-20459) Majority of scan CPU time in HBase-1 spent in size estimation

[ https://issues.apache.org/jira/browse/HBASE-20459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob reopened HBASE-20459: --- reopening to mark that this patch needs to go to branch-2 and branch-2.0 > Majority of scan CPU time in

Re: Tools for balancing a poorly distributed table

Definitely not normalizer - wasn’t enabled at that point. I believe it happened in 2 places because of: 1) poorly implemented bulk load pre-split strategy 2) integer keys and lots of row deletions Seem plausible? Thanks Tim, Sent from my iPhone > On 21 Apr 2018, at 19:29, Ted Yu

Re: Tools for balancing a poorly distributed table

>From your first email: bq. including some with many regions in the KB size Do you know if the above was result of the operation(s) from normalizer ? Since assuming you use standard max hfile size, there shouldn't be such small regions. Cheers On Sat, Apr 21, 2018 at 10:18 AM, Tim Robertson

Re: Tools for balancing a poorly distributed table

Thanks Ted, I should have been explicit - for the cases I've been working with they can make their apps effectively go "read-only" for this house keeping step. At the end a change of app config or a couple of table name changes (short outage) would be needed. I've been using the

Re: Tools for balancing a poorly distributed table

Looking at proposed flow, have you considered the new data coming in between steps #a and #d ? Also, how would client application switch between the original table and the new table ? BTW since you mentioned SimpleNormalizer, which release are you using (just want to see if all recent fixes to

Tools for balancing a poorly distributed table

Hi folks Recently I've seen a few clusters with badly unbalanced tables, including some with many regions in the KB size. It seems it is easy to overlook this in ops. Understandably SimpleNormalizer does a fairly poor job at addressing this - takes a long time, doesn't aggressively merge small

[jira] [Created] (HBASE-20472) InfoServer doesnot honour any acl set by the admin

Nihal Jain created HBASE-20472: -- Summary: InfoServer doesnot honour any acl set by the admin Key: HBASE-20472 URL: https://issues.apache.org/jira/browse/HBASE-20472 Project: HBase Issue Type:

[jira] [Created] (HBASE-20471) Recheck the design and implementation of FSYNC_WAL durability for WAL

Yu Li created HBASE-20471: - Summary: Recheck the design and implementation of FSYNC_WAL durability for WAL Key: HBASE-20471 URL: https://issues.apache.org/jira/browse/HBASE-20471 Project: HBase