Re: Retiring empty regions

>I'd love to hear your thoughts on this design, Vlad. Maybe you'd like to >write up a post for the blog? Meanwhile, I'm sure of a couple of us on here >on the list would appreciate your Cliff's Notes version. I can take this >into account for my v2 schema design. Nick, there will be a

Re: Retiring empty regions

> the shell and find the empty ones, another to merge a given region into a neighbor. We've run them without incident, looks like it all works fine. One thing we did notice is that the AM leaves the old "retired" regions around in its counts -- the master status page shows a large number of

Retiring empty regions

Yeah, that sound interesting. Do you think it should be a script (command, runnable from the client side), or some chore on master? You're going on this route because region normalizer lacks features you guys need? -Mikhail > Circling back here and adding user@phoenix. I put together one

Re: Retiring empty regions

Circling back here and adding user@phoenix. I put together one script to dump region info from the shell and find the empty ones, another to merge a given region into a neighbor. We've run them without incident, looks like it all works fine. One thing we did notice is that the AM leaves the old

Re: Failed open of region

On Wed, Apr 20, 2016 at 2:11 PM, Michal Medvecky wrote: > > > > NameNode is telling hbase they exist. Can you get some DEBUG in there? > You > > know how to set log levels? Could give us a clue. > > > > > I finally removed some lingering reference files and HBCK managed to fix

Re: Failed open of region

> > NameNode is telling hbase they exist. Can you get some DEBUG in there? You > know how to set log levels? Could give us a clue. > > I finally removed some lingering reference files and HBCK managed to fix the issue. Michal

Re: Hbase v1 vs 0.98x

The Release Announcements for the releases are probably the best source of 'What's New' in the releases. The release managers did their best to give a good summary; HBase 1.0.0 release

Re: zero data locality

This is from just one region server right? are you sure it is co-located with an HDFS data node after your upgrade? I imagine that is pretty obvious thing to check but the only thing I can think of. Saad On Wed, Apr 20, 2016 at 10:30 AM, Ted Tuttle wrote: > Hello-

Re: Major Compaction Strategy

Thanks for the pointer. Working like a charm. Saad On Tue, Apr 19, 2016 at 4:01 PM, Ted Yu wrote: > Please use the following method of HBaseAdmin: > > public CompactionState getCompactionStateForRegion(final byte[] > regionName) > > Cheers > > On Tue, Apr 19, 2016

Re: Sources Of HBase Client Side Latency

On Tue, Apr 19, 2016 at 11:14 PM, Neelesh wrote: > We have very similar issues with HBase 1.1.2, especially around splits. It > takes several minutes at times. We use phoenix with two global indexes and > we know that compounds the issue a bit, but about 95% of inserts take <

Re: Re: Re: single thread threadpool for master_table_operation

cp is coprocsssor this step is carried out before upgrade hbase, so after remove cp, old hbase will not be used so i want to increase the pool size in old version to speed up the process of removing cp On 2016-04-20 22:01 , Ted Yu Wrote: bq. all cp of all tables What does cp mean ? Do you

Re: Re: ERROR [main] client.ConnectionManager$HConnectionImplementation: The node /hbase is not in ZooKeeper.

bq. dataDir=/tmp/zookeeper When machine restarts, you would lose the data, right ? Please change to other directory. Was zookeeper.out from slave2 ? Please check port on 192.168.1.3 On Wed, Apr 20, 2016 at 6:22 AM, Eric Gao wrote: > Dear

zero data locality

Hello- We just upgraded to HBase 1.2. After the upgrade I see Data Locality is precisely zero for all regions of all regions servers. See screenshot here: https://snag.gy/2r3CSl This seems unlikely as I can see many major compactions of regions have occurred since our upgrade. Any ideas

Re: Re: single thread threadpool for master_table_operation

bq. all cp of all tables What does cp mean ? Do you mean column family ? bq. will never create/enable tables in the future Then what would the cluster be used for ? On Wed, Apr 20, 2016 at 6:16 AM, WangYQ wrote: > i want to remove all cp of all tables in hbase > so

Re: Re: ERROR [main] client.ConnectionManager$HConnectionImplementation: The node /hbase is not in ZooKeeper.

Dear Ted, Thank you for your kind attention. I'm a complete novice at Hadoop. ^___^ I have 3 host---1 master server and 2 data node,and zookeeper is installed on each server. Zookeeper and Hbase are still unable to start. Each server has the same status: [root@master data]#

Re:Re: single thread threadpool for master_table_operation

i want to remove all cp of all tables in hbase so i disable tables concurrently, and then modify tables for hundreds of tables, remove all cp costs 30 miniutes, is not so fast so, i want to speed the whoe process. and will never create/enable tables in the future after examine the code, i

Re: single thread threadpool for master_table_operation

Adding subject. Adding back user@hbase But the master wouldn't know what next action admin is going to perform, right ? On Wed, Apr 20, 2016 at 5:59 AM, WangYQ wrote: > if i just disable tables in concurrently, > and will never enable, modify, create table > > i

Re: (无主题)

Have you seen the comment above that line ? // We depend on there being only one instance of this executor running // at a time. To do concurrency, would need fencing of enable/disable of // tables. // Any time changing this maxThreads to > 1, pls see the comment at //

Re: Sources Of HBase Client Side Latency

Thanks, good advice. At a cursory glance at region server logs (didn't find anything interesting in master logs), I already see some GC pauses and complaints about "Slow sync cost". Will ask here with further details if need be after further analysis. Cheers. Saad On Tue, Apr 19, 2016 at

Re: Sources Of HBase Client Side Latency

We have very similar issues with HBase 1.1.2, especially around splits. It takes several minutes at times. We use phoenix with two global indexes and we know that compounds the issue a bit, but about 95% of inserts take < 50ms (with index writes included), but the remaining 5% are wild from 100ms