科技有限公司
>
> Virtue Intelligent Network Ltd, co.
>
> Add: 2003,20F No.35 Luojia creative city,Luoyu Road,Wuhan,HuBei
>
> Mob: +86 13797007811|Tel: + 86 27 5024 2516
>
>
>
> *发件人:* Nicolas Guyomar
> *发送时间:* 2018年4月20日 15:44
> *收件人:* user@cassandra.apache.org
> *主题:*
Hi,
You can have a look to
https://github.com/apache/cassandra/blob/trunk/NEWS.txt which list every
modification / advice for upgrading between each C* version
On 20 April 2018 at 09:25, Xiangfei Ni wrote:
> By the way,is there official documentation for online upgrade cassandra
> from 3.9 to
Jon,
Great article. Thank you. (I have nothing to do with this issue, but I
appreciate nuggets of information I glean from the list)
Regards,
Eric
On Tue, Apr 17, 2018 at 10:57 PM Jonathan Haddad wrote:
> To add to what Nate suggested, we have an entire blog post on scaling time
> series data
To add to what Nate suggested, we have an entire blog post on scaling time
series data models:
http://thelastpickle.com/blog/2017/08/02/time-series-data-modeling-massive-scale.html
Jon
On Tue, Apr 17, 2018 at 7:39 PM Nate McCall wrote:
> I disagree. Create date as a raw integer is an excellen
I disagree. Create date as a raw integer is an excellent surrogate for
controlling time series "buckets" as it gives you complete control over the
granularity. You can even have multiple granularities in the same table -
remember that partition key "misses" in Cassandra are pretty lightweight as
th
Hi David,
Could you describe why you chose to include the create date in the
partition key? If the vin in enough "partitioning", meaning that the size
(number of rows x size of row) of each partition is less than 100MB, then
remove the date and just use the create_time, because the date is already
Your table design will work fine as you have appropriately bucketed by an
integer-based 'create_date' field.
Your goal for this refactor should be to remove the "IN" clause from your
code. This will move the rollup of multiple partition keys being retrieved
into the client instead of relying on th
@cassandra.apache.org
Subject: RE: 答复: 答复: A node down every day in a 6 nodes cluster
If you think that will fix the problem, maybe you could add a little more
memory to each machine as a short term fix.
From: Xiangfei Ni [mailto:xiangfei...@cm-dt.com]
Sent: Wednesday, March 28, 2018 5:24 AM
To: user
2516
发件人: Kenneth Brotman
发送时间: 2018年3月28日 20:16
收件人: user@cassandra.apache.org
主题: RE: 答复: 答复: A node down every day in a 6 nodes cluster
David,
Did you figure out what to do about the data model problem? It could be that
your data files finally grow to the point that the data
model.
Kenneth Brotman
From: Kenneth Brotman [mailto:kenbrot...@yahoo.com]
Sent: Wednesday, March 28, 2018 4:46 AM
To: 'user@cassandra.apache.org'
Subject: RE: 答复: 答复: A node down every day in a 6 nodes cluster
Was any change to hardware done around the time the problem star
Virtue Intelligent Network Ltd, co.
Add: 2003,20F No.35 Luojia creative city,Luoyu Road,Wuhan,HuBei
Mob: +86 13797007811|Tel: + 86 27 5024 2516
发件人: Kenneth Brotman
发送时间: 2018年3月28日 19:34
收件人: user@cassandra.apache.org
主题: RE: 答复: 答复: A node down every day in a 6 nodes cluster
David
David,
How long has the cluster been operating?
How long has the problem been occurring?
Kenneth Brotman
From: Jeff Jirsa [mailto:jji...@gmail.com]
Sent: Tuesday, March 27, 2018 7:00 PM
To: Xiangfei Ni
Cc: user@cassandra.apache.org
Subject: Re: 答复: 答复: A node down every day in a 6
st Regards,
>
> 倪项菲/ David Ni
> 中移德电网络科技有限公司
> Virtue Intelligent Network Ltd, co.
>
> Add: 2003,20F No.35 Luojia creative city,Luoyu Road,Wuhan,HuBei
> Mob: +86 13797007811|Tel: + 86 27 5024 2516
>
> 发件人: Jeff Jirsa
> 发送时间: 2018年3月27日 11:50
> 收件人: Xiangfei Ni
ur suggestion is to first resolve the data model issue which
> cause wide partition,right?
>
> Best Regards,
>
> 倪项菲/ David Ni
> 中移德电网络科技有限公司
> Virtue Intelligent Network Ltd, co.
> Add: 2003,20F No.35 Luojia creative city,Luoyu Road,Wuhan,HuBei
> Mob: +86 13797007811|T
技有限公司
Virtue Intelligent Network Ltd, co.
Add: 2003,20F No.35 Luojia creative city,Luoyu Road,Wuhan,HuBei
Mob: +86 13797007811|Tel: + 86 27 5024 2516
发件人: Jeff Jirsa
发送时间: 2018年3月27日 11:50
收件人: Xiangfei Ni
抄送: user@cassandra.apache.org
主题: Re: 答复: A node down every day in a 6 nodes cluster
13797007811|Tel: + 86 27 5024 2516
发件人: Jeff Jirsa
发送时间: 2018年3月27日 11:50
收件人: Xiangfei Ni
抄送: user@cassandra.apache.org
主题: Re: 答复: A node down every day in a 6 nodes cluster
Only one node having the problem is suspicious. May be that your application is
improperly pooling connections, or you
Only one node having the problem is suspicious. May be that your
application is improperly pooling connections, or you have a hardware
problem.
I dont see anything in nodetool that explains it, though you certainly have
a data model likely to cause problems over time (the cardinality of
rt_ac_sta
Look for errors on your network interface. I think you have periodic errors
in your network connectivity
<==>
"Who do you think made the first stone spear? The Asperger guy.
If you get rid of the autism genetics, there would be no Silicon Valley"
Temple Grandin
*Daemeon C.M. ReiydelleSan Fr
>* wrote
>>>
>>> The solution maybe work. However, the play list will grow over time and
>>> somebody maybe has ten thousands that will slow down the query and sort .
>>> Do you mean the oldest one should be removed when a new play is added?
>>>
>>> BTW, the ve
that will slow down the query and sort .
>> Do you mean the oldest one should be removed when a new play is added?
>>
>> BTW, the version is 2.1.16 in our live system.
>>
>>
>> BRs,
>>
>> BEN
>> --
>>
>>
gt;
>>> On Wed, 09 Nov 2016 20:47:05 -0500*Diamond ben
>>> >* wrote
>>>
>>> The solution maybe work. However, the play list will grow over time and
>>> somebody maybe has ten thousands that will slow down the query and sort .
>>> Do you
list will grow over time and
>>> somebody maybe has ten thousands that will slow down the query and sort .
>>> Do you mean the oldest one should be removed when a new play is added?
>>>
>>> BTW, the version is 2.1.16 in our live system.
>>>
>>>
>
removed when a new play is added?
>>
>> BTW, the version is 2.1.16 in our live system.
>>
>>
>> BRs,
>>
>> BEN
>> --
>>
>> *发件人:* Vladimir Yudovin
>> *发送时间:* 2016年11月9日 18:11:26
>> *收件人:* user
ten thousands that will slow down the query and sort .
> Do you mean the oldest one should be removed when a new play is added?
>
> BTW, the version is 2.1.16 in our live system.
>
>
> BRs,
>
> BEN
> ------
>
> *发件人:* Vladimir Yudovin
>
is added?
BTW, the version is 2.1.16 in our live system.
BRs,
BEN
发件人: Vladimir Yudovin <vla...@winguzone.com>
发送时间: 2016年11月9日 18:11:26
收件人: user
主题: Re: 答复: A difficult data model with C*
You are welcome! )
>recent ten movies watched by the user within 30 days.
In this ca
You are welcome! )
>recent ten movies watched by the user within 30 days.
In this case you can't use PRIMARY KEY (user_name, video_id), as video_id is
demanded to fetch row, so all this stuff may be
CREATE TYPE play (video_id text, position int, last_time timestamp);
CREATE TABLE recent (use
Better yet, if you're using a client where you can pass the time in, you
can validate it is indeed clock skew. Do all your writes with timestamp =
0, all your deletes with timestamp = 1.
On Wed, Dec 24, 2014 at 7:47 AM, Ryan Svihla wrote:
> Every time I've heard this but one this has been clock
Why don't you use incremental repairs? Is there a known issue with
incremental repairs in 2.1.x?
On Tue, Dec 30, 2014 at 10:22 PM, 李建奇 wrote:
> We also suffer some problem from 2.1.2 . But I think we can deal with .
>
> First I don’t use incremental repair.
>
> Second we restart node after repa
Every time I've heard this but one this has been clock skew (and that was
swallowed exceptions), however it can just be you have a test that is prone
to race conditions (delete followed by an immediate select with a low
consistency level), without more detail it's hard to say.
I'd check the nodes
It does appear to be a ulimit issue to some degree as some settings are
lower than recommended by a few factors (namely nproc).
http://www.datastax.com/documentation/cassandra/2.0/cassandra/install/installRecommendSettings.html
* - memlock unlimited
* - nofile 10
* - nproc 32768
* - as unlimi
Hi,
It looks like you are running into a known issue:
https://issues.apache.org/jira/browse/CASSANDRA-7780 and its being worked
on here: https://issues.apache.org/jira/browse/CASSANDRA-7145
Mark
On 20 August 2014 09:06, 鄢来琼 wrote:
> Is it related to MAX_HEAP_SIZE and HEAP_NEWSIZE?
>
> My sy
On 12/02/2013 03:43 PM, Kumar Ranjan wrote:
> Hey Folks,
>
> I have been using ccm for some time and it's pretty awesome tool to test
> out admin stuff. Now, I really want to test modeling data by trying to
> access ccm running cassandra using Thrift based pycassaShell client from
> remote hosts (
Hey why dont you try Datastax Opscenter? Its a cool Gui tool to
start/stop/manage your cluster(even remotely) . It also provides
administrative tools fr checking on the performance with vital statistics.
Definitely worth it.
On Dec 3, 2013 3:14 AM, "Kumar Ranjan" wrote:
> Hey Folks,
>
> I have b
Hey Folks,
I have been using ccm for some time and it's pretty awesome tool to test
out admin stuff. Now, I really want to test modeling data by trying to
access ccm running cassandra using Thrift based pycassaShell client from
remote hosts (not locally). My setup is like this:
Lets say, private
Your ParNew size is way too small. Generally 4GB ParNew (-Xmn) works out
best for 16GB heap
On Mon, Sep 23, 2013 at 9:05 PM, 谢良 wrote:
> it looks to me that "MaxTenuringThreshold" is too small, do you have any
> chance to try with a bigger one, like 4 or 8 or sth else?
>
> __
You have to log in and then you can create topic only below some sections
(opscenter, feedbacks, ...) if I remember well.
Alain
2013/8/1 yue.zhang
> thanks Alain
>
> ** **
>
> I don’t know why not permited to create topic on datastax forum*.*
>
> ** **
>
> ** **
>
> *发件人:* Alain RODRIGUEZ
36 matches
Mail list logo
