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
Issu
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: Bu
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 re
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 Si
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 SimpleNormalizer
>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
wr
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 wrote:
>
>
[
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
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
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 that
[
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 sp
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 wit
12 matches
Mail list logo