On Fri, Feb 28, 2014 at 1:15 AM, kiran wrote:
> Also Initially we though it was human error that some one might have
> deleted hdfs dirs under some regions. But, surprisingy only some columns in
> a column family for a row in the region are lost. If some one has deleted
> entire dir, then entire
o: user@hbase.apache.org
>Sent: Thursday, February 27, 2014 7:53 AM
>Subject: Hbase data loss scenario
>
>
>
>Hi All,
>
>We have been experiencing severe data loss issues from few hours. There are
>some wierd things going on in the cluster. We were unable to locate the
>
user@hbase.apache.org
> Sent: Thursday, February 27, 2014 7:53 AM
> Subject: Hbase data loss scenario
>
>
> Hi All,
>
> We have been experiencing severe data loss issues from few hours. There are
> some wierd things going on in the cluster. We were unable to locate the
> data
er?
Can access any data at all?
-- Lars
From: kiran
To: user@hbase.apache.org
Sent: Thursday, February 27, 2014 7:53 AM
Subject: Hbase data loss scenario
Hi All,
We have been experiencing severe data loss issues from few hours. There are
some wierd things
On Thu, Feb 27, 2014 at 10:51 AM, kiran wrote:
> Is there any place where hdfs command history is stored on lines
> .bash_history in shell. Since the regions have increased for the table
> about 100 over a night (From 120 to 211)... I am suspecting that some thing
> is wrong from hbase side...
>
Is there any place where hdfs command history is stored on lines
.bash_history in shell. Since the regions have increased for the table
about 100 over a night (From 120 to 211)... I am suspecting that some thing
is wrong from hbase side...
On Fri, Feb 28, 2014 at 12:07 AM, kiran wrote:
> TTL se
TTL setting is Integer.MAX_VALUE. so it should not be problem.
On Thu, Feb 27, 2014 at 11:49 PM, Jimmy Xiang wrote:
> Hi Kiran,
>
> Can you check your table TTL setting? Is it possible that the data are
> expired and purged?
>
> Thanks,
> Jimmy
>
>
>
> On Thu, Feb 27, 2014 at 10:11 AM, Stack w
Hi Kiran,
Can you check your table TTL setting? Is it possible that the data are
expired and purged?
Thanks,
Jimmy
On Thu, Feb 27, 2014 at 10:11 AM, Stack wrote:
> Anything in your logs that might give you a clue? Master logs? HDFS
> NameNode logs?
> St.Ack
>
>
> On Thu, Feb 27, 2014 at 7:
Anything in your logs that might give you a clue? Master logs? HDFS
NameNode logs?
St.Ack
On Thu, Feb 27, 2014 at 7:53 AM, kiran wrote:
> Hi All,
>
> We have been experiencing severe data loss issues from few hours. There are
> some wierd things going on in the cluster. We were unable to loca
Hi Jean,
This is the scenario i am talking about... Let me know if every thing is ok
with this region chain
Regionname StartKey Endkey
RAW,GpsgQ,1393477054705.defb006868d8191e76a2ae7e9d203419. GpsgQ G7stL
RAW,G7stL,1393477054705.0d123f246312f937e930fc76fc8d4b9c. G7stL HCuv
RAW,HCuv,139349069
Hi Kiran,
2 things.
1) Is there any reason for you to use a so old HBase version? any chance to
migrate to a more recent one? 0.94.17 is out.
2) What do you mean by "I have never seen a wierd start key and end key
like this"? I don't see anything wrong with what you described. What you
keys look
Adding to that there are many regions with 0MB size and have CF's as
specified in the table...
On Thu, Feb 27, 2014 at 9:23 PM, kiran wrote:
> Hi All,
>
> We have been experiencing severe data loss issues from few hours. There
> are some wierd things going on in the cluster. We were unable to l
Hi All,
We have been experiencing severe data loss issues from few hours. There are
some wierd things going on in the cluster. We were unable to locate the
data even in hdfs
Hbase version 0.94.1
Here is the wierd things that are going on:
1) Table which was once 1TB has now become 170GB with ma
13 matches
Mail list logo