Re: I wonder if that the 'backspace' key can't take effect during create a table

2017-05-01 Thread Allan Yang
press Control + Backspace

2017-05-02 12:45 GMT+08:00 QI Congyun :

> Hello expert,
>
> The HBASE is configured, there are 3 node b in my test environment, the
> 1st node is master, the 2nd and 3th is region-servers.
>
> When the Hbase is launched via the command 'start-hbase.sh', I try to
> create a new table by HBase shell.
>
> I can create some tables via HBASE shell. But I don't understand why the
> character can't be deleted by click the 'backspace' key of the key-board if
> some wrong character is input via the key-board? I wonder if the incorrect
> character can' be deleted at the HBASE shell or some incorrect
> configuration is done?
>
> Thanks.
>
>


I wonder if that the 'backspace' key can't take effect during create a table

2017-05-01 Thread QI Congyun
Hello expert,

The HBASE is configured, there are 3 node b in my test environment, the 1st 
node is master, the 2nd and 3th is region-servers.

When the Hbase is launched via the command 'start-hbase.sh', I try to create a 
new table by HBase shell.

I can create some tables via HBASE shell. But I don't understand why the 
character can't be deleted by click the 'backspace' key of the key-board if 
some wrong character is input via the key-board? I wonder if the incorrect 
character can' be deleted at the HBASE shell or some incorrect configuration is 
done?

Thanks.



Re: stop-hbase.sh is not stopping regionservers

2017-05-01 Thread ManojK
jus will show the processid.No need to go for ps-ef.
currently below process ids are running in my terminal

$ jps
15312 NodeManager
18146 HRegionServer
18532 RunJar
18213 Main
15576 HQuorumPeer
15113 SecondaryNameNode
15225 ResourceManager
14923 NameNode
18750 Jps
15007 DataNode




--
View this message in context: 
http://apache-hbase.679495.n3.nabble.com/stop-hbase-sh-is-not-stopping-regionservers-tp4025660p4087770.html
Sent from the HBase User mailing list archive at Nabble.com.


Does HBase REST API support bulk delete?

2017-05-01 Thread Duo
Hi experts,

I noticed that RemoteHTable supports bulk delete

delete(List deletes)
Deletes the specified cells/rows in bulk.


However from some online documentations, for example,

https://archive.cloudera.com/cdh5/cdh/5/hbase/apidocs/org/apache/hadoop/hbase/rest/package-summary.html

I cannot find REST APIs to do bulk delete. I can find REST APIs to do bulk
insert by specifying a false row key in the REST url.

Is bulk delete supported in REST APIs in HBase?

Thanks,
Duo


Re: stop-hbase.sh is not stopping regionservers

2017-05-01 Thread Ted Yu
jps may not show the process.

Have you tried using 'ps' command to check 13827 ?

Which hbase release are you using ?

Did you make any non-default config change ?

Cheers

On Mon, May 1, 2017 at 1:41 AM, ManojK  wrote:

> Hi,
>
> Its internal...and from jps track the process running for regionserver.
> and stop it with kill -9 pid
>
> $ start-hbase.sh
> localhost: starting zookeeper, logging to
> /Users/Aditya/Big_Data/hbase-1.0.3/logs/hbase-Aditya-
> zookeeper-Manojs-MacBook-Air.local.out
> starting master, logging to
> /Users/Aditya/Big_Data/hbase-1.0.3/logs/hbase-Aditya-
> master-Manojs-MacBook-Air.local.out
> regionserver running as process 13827. Stop it first.
>
> $kill -9 13827
> $jps ---it will not show region server
>
>
>
> --
> View this message in context: http://apache-hbase.679495.n3.
> nabble.com/stop-hbase-sh-is-not-stopping-regionservers-
> tp4025660p4087763.html
> Sent from the HBase User mailing list archive at Nabble.com.
>


Re: stop-hbase.sh is not stopping regionservers

2017-05-01 Thread ManojK
Hi,

Its internal...and from jps track the process running for regionserver.
and stop it with kill -9 pid

$ start-hbase.sh
localhost: starting zookeeper, logging to
/Users/Aditya/Big_Data/hbase-1.0.3/logs/hbase-Aditya-zookeeper-Manojs-MacBook-Air.local.out
starting master, logging to
/Users/Aditya/Big_Data/hbase-1.0.3/logs/hbase-Aditya-master-Manojs-MacBook-Air.local.out
regionserver running as process 13827. Stop it first.

$kill -9 13827
$jps ---it will not show region server



--
View this message in context: 
http://apache-hbase.679495.n3.nabble.com/stop-hbase-sh-is-not-stopping-regionservers-tp4025660p4087763.html
Sent from the HBase User mailing list archive at Nabble.com.


Re: HBase 1.0 Per Put TTL Not Being Obeyed On Replication

2017-05-01 Thread Saad Mufti
Thx. Will try and see what I can find.


Saad

On Mon, May 1, 2017 at 5:41 AM Anoop John  wrote:

> At server side (RS) as well as at client side, put the config
> "hbase.client.rpc.codec" with a value
> org.apache.hadoop.hbase.codec.KeyValueCodecWithTags. Then u will
> be able to retrieve the tags back to client side and check
>
> -Anoop-
>
> On Mon, May 1, 2017 at 2:59 AM, Saad Mufti  wrote:
> > Is there any facility to check what tags are on a Cell from a client side
> > program? I started writing some Java code to look at the tags on a Cell
> > retrieved via a simple Get, but then started reading around and it seems
> > tags are not even returned (not returned at all or only in certain cases,
> > I'm not clear) to client side code. So how can I verify that a Cell in
> one
> > cluster has the TTL tag whereas the same replicated C3ell in the next
> > cluster does or doesn't?
> >
> > Thanks.
> >
> > 
> > Saad
> >
> >
> > On Fri, Apr 28, 2017 at 1:06 PM, Saad Mufti 
> wrote:
> >
> >> Thanks for the feedback, I have confirmed that in both the main and
> >> replica cluster, hbase.replication.rpc.codec is set to:
> >>
> >> org.apache.hadoop.hbase.codec.KeyValueCodecWithTags
> >>
> >> I have also run a couple of tests and it looks like the TTL is not being
> >> obeyed on the replica for any entry. Almost as if the TTL cell tags are
> not
> >> being replicated. I couldn't find any significant clock skew. If it
> >> matters, the HBase version on both sides is 1.0.0-cdh5.5.2
> >>
> >> Any ideas?
> >>
> >> Thanks.
> >>
> >> 
> >> Saad
> >>
> >>
> >> On Thu, Apr 27, 2017 at 3:24 AM, Anoop John 
> wrote:
> >>
> >>> Ya can u check whether the replica cluster is NOT removing ANY of the
> >>> TTL expired cells (as per ur expectation from master cluster) or some.
> >>> Is there too much clock time skew for the source RS and peer cluster
> >>> RS? Just check.
> >>>
> >>> BTW can u see what is the hbase.replication.rpc.codec configuration
> >>> value in both clusters?
> >>>
> >>> -Anoop-
> >>>
> >>> On Thu, Apr 27, 2017 at 2:08 AM, Saad Mufti 
> wrote:
> >>> > Hi,
> >>> >
> >>> > I have a main HBase 1.x cluster and some of the tables are being
> >>> replicated
> >>> > to a separate HBase cluster of the same version, and the table
> schemas
> >>> are
> >>> > identical. The column family being used has TTL set to "FOREVER", but
> >>> we do
> >>> > a per put TTL in every Put we issue on the main cluster.
> >>> >
> >>> > Data is being replicated but we recently caught a number of data
> items
> >>> that
> >>> > have disappeared in the main cluster as expected based on their TTL
> but
> >>> not
> >>> > in the replica. Both HBase clusters have hfile.format.version set to
> 3
> >>> so
> >>> > TTL tags should be obeyed. I haven't checked yet whether it is a
> case of
> >>> > the replica not obeying ANY TTL's or just some.
> >>> >
> >>> > Before we dig deeper, I was hoping someone in the community would
> point
> >>> it
> >>> > out if we have missed any obvious gotchas.
> >>> >
> >>> > Thanks.
> >>> >
> >>> > ---
> >>> > Saad
> >>>
> >>
> >>
>


Re: HBase 1.0 Per Put TTL Not Being Obeyed On Replication

2017-05-01 Thread Anoop John
At server side (RS) as well as at client side, put the config
"hbase.client.rpc.codec" with a value
org.apache.hadoop.hbase.codec.KeyValueCodecWithTags. Then u will
be able to retrieve the tags back to client side and check

-Anoop-

On Mon, May 1, 2017 at 2:59 AM, Saad Mufti  wrote:
> Is there any facility to check what tags are on a Cell from a client side
> program? I started writing some Java code to look at the tags on a Cell
> retrieved via a simple Get, but then started reading around and it seems
> tags are not even returned (not returned at all or only in certain cases,
> I'm not clear) to client side code. So how can I verify that a Cell in one
> cluster has the TTL tag whereas the same replicated C3ell in the next
> cluster does or doesn't?
>
> Thanks.
>
> 
> Saad
>
>
> On Fri, Apr 28, 2017 at 1:06 PM, Saad Mufti  wrote:
>
>> Thanks for the feedback, I have confirmed that in both the main and
>> replica cluster, hbase.replication.rpc.codec is set to:
>>
>> org.apache.hadoop.hbase.codec.KeyValueCodecWithTags
>>
>> I have also run a couple of tests and it looks like the TTL is not being
>> obeyed on the replica for any entry. Almost as if the TTL cell tags are not
>> being replicated. I couldn't find any significant clock skew. If it
>> matters, the HBase version on both sides is 1.0.0-cdh5.5.2
>>
>> Any ideas?
>>
>> Thanks.
>>
>> 
>> Saad
>>
>>
>> On Thu, Apr 27, 2017 at 3:24 AM, Anoop John  wrote:
>>
>>> Ya can u check whether the replica cluster is NOT removing ANY of the
>>> TTL expired cells (as per ur expectation from master cluster) or some.
>>> Is there too much clock time skew for the source RS and peer cluster
>>> RS? Just check.
>>>
>>> BTW can u see what is the hbase.replication.rpc.codec configuration
>>> value in both clusters?
>>>
>>> -Anoop-
>>>
>>> On Thu, Apr 27, 2017 at 2:08 AM, Saad Mufti  wrote:
>>> > Hi,
>>> >
>>> > I have a main HBase 1.x cluster and some of the tables are being
>>> replicated
>>> > to a separate HBase cluster of the same version, and the table schemas
>>> are
>>> > identical. The column family being used has TTL set to "FOREVER", but
>>> we do
>>> > a per put TTL in every Put we issue on the main cluster.
>>> >
>>> > Data is being replicated but we recently caught a number of data items
>>> that
>>> > have disappeared in the main cluster as expected based on their TTL but
>>> not
>>> > in the replica. Both HBase clusters have hfile.format.version set to 3
>>> so
>>> > TTL tags should be obeyed. I haven't checked yet whether it is a case of
>>> > the replica not obeying ANY TTL's or just some.
>>> >
>>> > Before we dig deeper, I was hoping someone in the community would point
>>> it
>>> > out if we have missed any obvious gotchas.
>>> >
>>> > Thanks.
>>> >
>>> > ---
>>> > Saad
>>>
>>
>>