Re: Questions regarding DataStax AMI

[Joaquin Casares]

Oh you're right, sorry about that. The concept of keeping older packages
was recently implemented and while using --version community, you would
need --release 1.0 in order to get 1.0.10.

If you are using --version enterprise, you can use --release 2.0 to get
DataStax Enterprise 2.0 which comes bundled with 1.0.8. As long as you
don't include --analyticsnodes or --searchnodes, you will get vanilla
Cassandra.

As of now, those are the only options available.

Thanks for pointing that out and sorry about the confusion,

Joaquin Casares
DataStax
Software Engineer/Support



On Fri, Jul 27, 2012 at 3:50 AM, Tamar Fraenkel  wrote:

> HI!
> I tried starting a cluster with
> Cluster started with these options:
> --clustername  --totalnodes 3 --version community --release 1.0.8
>
> But Cassandra's version is 1.1.2
> Thanks
>
> *Tamar Fraenkel *
> Senior Software Engineer, TOK Media
>
> [image: Inline image 1]
>
>
> ta...@tok-media.com
> Tel:   +972 2 6409736
> Mob:  +972 54 8356490
> Fax:   +972 2 5612956
>
>
>
>
>
> On Thu, Jul 26, 2012 at 9:56 PM, Tamar Fraenkel wrote:
>
>> What should be the value to create it with Cassandra 1.0.8
>> Tamar
>>
>> Sent from my iPod
>>
>> On Jul 26, 2012, at 7:06 PM, Joaquin Casares 
>> wrote:
>>
>> Yes, you can easily do this by using the --release  switch as
>> found here:
>> http://www.datastax.com/docs/1.0/install/install_ami
>>
>> Thanks,
>>
>> Joaquin Casares
>> DataStax
>> Software Engineer/Support
>>
>>
>>
>> On Thu, Jul 26, 2012 at 12:44 AM, Tamar Fraenkel wrote:
>>
>>> Hi!
>>> Is there a way to launch EC2 cluster from DataStax latest community AMI
>>> that will run Cassandra 1.0.8 and not 1.1.2?
>>> Thanks
>>>  *Tamar Fraenkel *
>>> Senior Software Engineer, TOK Media
>>>
>>> 
>>>
>>>
>>> ta...@tok-media.com
>>> Tel:   +972 2 6409736
>>> Mob:  +972 54 8356490
>>> Fax:   +972 2 5612956
>>>
>>>
>>>
>>>
>>>
>>
>
<>

Re: increased RF and repair, not working?

[Riyad Kalla]

Dave,

What I was suggesting for Yan was to:

WRITE: RF=2, CL=QUORUM
READ: CL=ONE

But you have a good pt... if he hits one of the replicas that didn't have
the data, that would be bad.

Thanks for clearing that up.

On Fri, Jul 27, 2012 at 11:43 AM, Dave Brosius wrote:

> You have RF=2, CL= Quorum but 3 nodes.
>
> So each row is represented on 2 of the 3 nodes.
>
> If you take a node down, one of two things can happen when you attempt to
> read a row.
>
> The row lives on the two nodes that are still up. In this case you will
> successfully read the data.
>
> The row lives on one node that is up, and one node that is down. In this
> case the read will fail because you haven't fulfilled the quorum (2 nodes
> in agreement) requirement.
>
>
> *- Original Message -*
> *From:* "Riyad Kalla" 
> *Sent:* Fri, July 27, 2012 8:08
> *Subject:* Re: increased RF and repair, not working?
>
> Dave, per my understanding of Yan's description he has 3 nodes and took
> one down manually to test; that should have worked, no?
>
> On Thu, Jul 26, 2012 at 11:00 PM, Dave Brosius 
> wrote:
>
>> Quorum is defined as
>>
>> (replication_factor / 2) + 1
>> therefore quorum when rf = 2 is 2! so in your case, both nodes must be up.  
>> Really, using Quorum only starts making sense as a 'quorum' when RF=3
>>
>>
>>
>>
>>
>>
>> On 07/26/2012 10:38 PM, Yan Chunlu wrote:
>>
>> I am using Cassandra 1.0.2, have a 3 nodes cluster. the consistency level
>> of read & write are  both QUORUM.
>>
>> At first the RF=1, and I figured that one node down will cause the
>> cluster unusable. so I changed RF to 2, and run nodetool repair on every
>> node(actually I did it twice).
>>
>> After the operation I think my data should be in at least two nodes, and
>> it would be okay if one of them is down.
>>
>> But when I tried to simulate the failure, by disablegossip of one node,
>> and the cluster knows this node is dow n. then access data from the
>> cluster, it returned  "MaximumRetryException"(pycassa).   as my experiences
>> this is caused by "UnavailableException", which is means the data it is
>> requesting is on a node which is down.
>>
>> so I wonder my data might not be replicated right, what should I do?
>> thanks for the help!
>>
>> here is the keyspace info:
>>
>> *
>> *
>> *Keyspace: comments:*
>> *  Replication Strategy: org.apache.cassandra.locator.SimpleStrategy*
>>  *  Durable Writes: true*
>> *Options: [replication_factor:2]*
>>
>>
>>
>> the scheme version is okay:
>>
>> *[default@unknown] describe cluster;*
>> *Cluster Information:*
>> *   Snitch: org.apache.cassandra.locator.SimpleSnitch*
>>  *   Partitioner: org.apache.cassandra.dht.RandomPartitioner*
>> *   Schema versions: *
>> * f67d0d50-b923-11e1--4f7cf9240aef: [192.168.1.129, 192.168.1.40,
>> 192.168.1.50]*
>>
>>
>>
>> the loads are as below:
>>
>> *nodetool -h localhost ring*
>> *Address DC  RackStatus State   Load
>>   ;OwnsToken   *
>> *
>>113427455640312821154458202477256070484 *
>> *192.168.1.50datacenter1 rack1   Up Normal  28.77 GB
>>  33.33%  0   *
>> *192.168.1.40datacenter1 rac k1   Up Normal  26.67 GB
>>  33.33%  56713727820156410577229101238628035242  *
>> *192.168.1.129   datacenter1 rack1   Up Normal  33.25 GB
>>  33.33%  113427455640312821154458202477256070484*
>>
>>
>

Re: Connection issue in Cassandra

[Tyler Hobbs]

On Thu, Jul 26, 2012 at 11:25 PM, Adeel Akbar  wrote:

>  I used Cassandra 0.8.1 and pycasa 0.2. If I upgrade pycasa, then it have
> compatibility issue. please suggest
>

You can use the latest version of pycassa with Cassandra 0.8.

-- 
Tyler Hobbs
DataStax 

Re: increased RF and repair, not working?

[Dave Brosius]

You have RF=2, CL= Quorum but 3 nodes. So each row is represented on 2 of the 3 
nodes.If you take a node down, one of two things can happen when you attempt to 
read a row.The row lives on the two nodes that are still up. In this case you 
will successfully read the data.The row lives on one node that is up, and one 
node that is down. In this case the read will fail because you haven't 
fulfilled the quorum (2 nodes in agreement) requirement.   - Original 
Message -From: "Riyad Kalla" >;rka...@gmail.com 

Re: Unsubscribe

[Tyler Hobbs]

http://wiki.apache.org/cassandra/FAQ#unsubscribe

On Fri, Jul 27, 2012 at 9:46 AM, Samir Rayani wrote:

>
>


-- 
Tyler Hobbs
DataStax 

Re: increased RF and repair, not working?

[Riyad Kalla]

Ah!

Yan I think you want your writes to use QUORUM and your reads to just be a
single node right?

If you need/want the read-repair, then I suppose you would need more nodes
up (or deployed in your cluster) but if you are keeping 3 machines a RF of
2 with a write consistency of 2 and a read of 1 should give you good
behavior with what you have now.

On Fri, Jul 27, 2012 at 8:56 AM, Yan Chunlu  wrote:

> I think Dave is right,  I have read this article again:
> http://thelastpickle.com/2011/07/04/Cassandra-Query-Plans/
>
> I have data on two nodes, and "QUORUM read" means it need read from both
> two nodes.
>
> I guess I need to increase the RF to 3, to make the system can tolerance
> one node failure.
>
> thanks for all of the kind help!
>
> On Fri, Jul 27, 2012 at 8:08 PM, Riyad Kalla  wrote:
>
>> Dave, per my understanding of Yan's description he has 3 nodes and took
>> one down manually to test; that should have worked, no?
>>
>>
>> On Thu, Jul 26, 2012 at 11:00 PM, Dave Brosius 
>> wrote:
>>
>>>  Quorum is defined as
>>>
>>> (replication_factor / 2) + 1
>>> therefore quorum when rf = 2 is 2! so in your case, both nodes must be up.
>>>
>>> Really, using Quorum only starts making sense as a 'quorum' when RF=3
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 07/26/2012 10:38 PM, Yan Chunlu wrote:
>>>
>>> I am using Cassandra 1.0.2, have a 3 nodes cluster. the consistency
>>> level of read & write are  both QUORUM.
>>>
>>>  At first the RF=1, and I figured that one node down will cause the
>>> cluster unusable. so I changed RF to 2, and run nodetool repair on every
>>> node(actually I did it twice).
>>>
>>>  After the operation I think my data should be in at least two nodes,
>>> and it would be okay if one of them is down.
>>>
>>> But when I tried to simulate the failure, by disablegossip of one node,
>>> and the cluster knows this node is down. then access data from the cluster,
>>> it returned  "MaximumRetryException"(pycassa).   as my experiences this is
>>> caused by "UnavailableException", which is means the data it is requesting
>>> is on a node which is down.
>>>
>>>  so I wonder my data might not be replicated right, what should I do?
>>> thanks for the help!
>>>
>>>  here is the keyspace info:
>>>
>>>  *
>>> *
>>>  *Keyspace: comments:*
>>> *  Replication Strategy: org.apache.cassandra.locator.SimpleStrategy*
>>> *  Durable Writes: true*
>>> *Options: [replication_factor:2]*
>>>
>>>
>>>
>>>  the scheme version is okay:
>>>
>>>  *[default@unknown] describe cluster;*
>>> *Cluster Information:*
>>> *   Snitch: org.apache.cassandra.locator.SimpleSnitch*
>>> *   Partitioner: org.apache.cassandra.dht.RandomPartitioner*
>>> *   Schema versions: *
>>> * f67d0d50-b923-11e1--4f7cf9240aef: [192.168.1.129, 192.168.1.40,
>>> 192.168.1.50]*
>>>
>>>
>>>
>>>  the loads are as below:
>>>
>>>  *nodetool -h localhost ring*
>>> *Address DC  RackStatus State   Load
>>>  OwnsToken   *
>>> *
>>>  113427455640312821154458202477256070484 *
>>> *192.168.1.50datacenter1 rack1   Up Normal  28.77 GB
>>>  33.33%  0   *
>>> *192.168.1.40datacenter1 rack1   Up Normal  26.67 GB
>>>  33.33%  56713727820156410577229101238628035242  *
>>> *192.168.1.129   datacenter1 rack1   Up Normal  33.25 GB
>>>  33.33%  113427455640312821154458202477256070484*
>>>
>>>
>>>
>>
>

Re: increased RF and repair, not working?

[Yan Chunlu]

I think Dave is right,  I have read this article again:
http://thelastpickle.com/2011/07/04/Cassandra-Query-Plans/

I have data on two nodes, and "QUORUM read" means it need read from both
two nodes.

I guess I need to increase the RF to 3, to make the system can tolerance
one node failure.

thanks for all of the kind help!
On Fri, Jul 27, 2012 at 8:08 PM, Riyad Kalla  wrote:

> Dave, per my understanding of Yan's description he has 3 nodes and took
> one down manually to test; that should have worked, no?
>
>
> On Thu, Jul 26, 2012 at 11:00 PM, Dave Brosius 
> wrote:
>
>>  Quorum is defined as
>>
>> (replication_factor / 2) + 1
>> therefore quorum when rf = 2 is 2! so in your case, both nodes must be up.
>>
>> Really, using Quorum only starts making sense as a 'quorum' when RF=3
>>
>>
>>
>>
>>
>>
>> On 07/26/2012 10:38 PM, Yan Chunlu wrote:
>>
>> I am using Cassandra 1.0.2, have a 3 nodes cluster. the consistency level
>> of read & write are  both QUORUM.
>>
>>  At first the RF=1, and I figured that one node down will cause the
>> cluster unusable. so I changed RF to 2, and run nodetool repair on every
>> node(actually I did it twice).
>>
>>  After the operation I think my data should be in at least two nodes,
>> and it would be okay if one of them is down.
>>
>> But when I tried to simulate the failure, by disablegossip of one node,
>> and the cluster knows this node is down. then access data from the cluster,
>> it returned  "MaximumRetryException"(pycassa).   as my experiences this is
>> caused by "UnavailableException", which is means the data it is requesting
>> is on a node which is down.
>>
>>  so I wonder my data might not be replicated right, what should I do?
>> thanks for the help!
>>
>>  here is the keyspace info:
>>
>>  *
>> *
>>  *Keyspace: comments:*
>> *  Replication Strategy: org.apache.cassandra.locator.SimpleStrategy*
>> *  Durable Writes: true*
>> *Options: [replication_factor:2]*
>>
>>
>>
>>  the scheme version is okay:
>>
>>  *[default@unknown] describe cluster;*
>> *Cluster Information:*
>> *   Snitch: org.apache.cassandra.locator.SimpleSnitch*
>> *   Partitioner: org.apache.cassandra.dht.RandomPartitioner*
>> *   Schema versions: *
>> * f67d0d50-b923-11e1--4f7cf9240aef: [192.168.1.129, 192.168.1.40,
>> 192.168.1.50]*
>>
>>
>>
>>  the loads are as below:
>>
>>  *nodetool -h localhost ring*
>> *Address DC  RackStatus State   Load
>>  OwnsToken   *
>> *
>>113427455640312821154458202477256070484 *
>> *192.168.1.50datacenter1 rack1   Up Normal  28.77 GB
>>  33.33%  0   *
>> *192.168.1.40datacenter1 rack1   Up Normal  26.67 GB
>>  33.33%  56713727820156410577229101238628035242  *
>> *192.168.1.129   datacenter1 rack1   Up Normal  33.25 GB
>>  33.33%  113427455640312821154458202477256070484*
>>
>>
>>
>

Re: increased RF and repair, not working?

[Riyad Kalla]

Dave, per my understanding of Yan's description he has 3 nodes and took one
down manually to test; that should have worked, no?

On Thu, Jul 26, 2012 at 11:00 PM, Dave Brosius wrote:

>  Quorum is defined as
>
> (replication_factor / 2) + 1
> therefore quorum when rf = 2 is 2! so in your case, both nodes must be up.
>
> Really, using Quorum only starts making sense as a 'quorum' when RF=3
>
>
>
>
>
>
> On 07/26/2012 10:38 PM, Yan Chunlu wrote:
>
> I am using Cassandra 1.0.2, have a 3 nodes cluster. the consistency level
> of read & write are  both QUORUM.
>
>  At first the RF=1, and I figured that one node down will cause the
> cluster unusable. so I changed RF to 2, and run nodetool repair on every
> node(actually I did it twice).
>
>  After the operation I think my data should be in at least two nodes, and
> it would be okay if one of them is down.
>
> But when I tried to simulate the failure, by disablegossip of one node,
> and the cluster knows this node is down. then access data from the cluster,
> it returned  "MaximumRetryException"(pycassa).   as my experiences this is
> caused by "UnavailableException", which is means the data it is requesting
> is on a node which is down.
>
>  so I wonder my data might not be replicated right, what should I do?
> thanks for the help!
>
>  here is the keyspace info:
>
>  *
> *
>  *Keyspace: comments:*
> *  Replication Strategy: org.apache.cassandra.locator.SimpleStrategy*
> *  Durable Writes: true*
> *Options: [replication_factor:2]*
>
>
>
>  the scheme version is okay:
>
>  *[default@unknown] describe cluster;*
> *Cluster Information:*
> *   Snitch: org.apache.cassandra.locator.SimpleSnitch*
> *   Partitioner: org.apache.cassandra.dht.RandomPartitioner*
> *   Schema versions: *
> * f67d0d50-b923-11e1--4f7cf9240aef: [192.168.1.129, 192.168.1.40,
> 192.168.1.50]*
>
>
>
>  the loads are as below:
>
>  *nodetool -h localhost ring*
> *Address DC  RackStatus State   Load
>  OwnsToken   *
> *
>113427455640312821154458202477256070484 *
> *192.168.1.50datacenter1 rack1   Up Normal  28.77 GB
>  33.33%  0   *
> *192.168.1.40datacenter1 rack1   Up Normal  26.67 GB
>  33.33%  56713727820156410577229101238628035242  *
> *192.168.1.129   datacenter1 rack1   Up Normal  33.25 GB
>  33.33%  113427455640312821154458202477256070484*
>
>
>

Re: Unreachable node, not in nodetool ring

[Olivier Mallassi]

nope
my last ideas would be (and I am not sure these are the best)
- try removetoken with -f option. I do not believe it will change anything
but...
- try nodeltool ring on ALL nodes and check all nodes see the unreachable
node. If not, you could maybe juste decommission the one(s) that see the
unreachable node.
- If you are in test, you can delete the system folder (subfolder of where
all your data are saved (data_directory in cassandra.yaml, by default
/var/lib/cassandra/data).
*but you will lose everything*
- snapshot data and restore them in another cluster. not that simple
depending on data volume, traffic etc

>From my side, I do not have more ideas...and once again, I am not the sure
these ones are the best ;)

I do not know if cassandra is able to definitively consider a node as dead
after a certain amount of time.


On Fri, Jul 27, 2012 at 11:04 AM, Alain RODRIGUEZ wrote:

> Hi again,
>
> Nobody has a clue about this issue ?
>
> I'm still facing this problem.
>
> Alain
>
> 2012/7/23 Alain RODRIGUEZ :
> > Does anyone knows how to totally remove a dead node that only appears
> > when doing a "describe cluster" from the cli ?
> >
> > I still got this issue in my production cluster.
> >
> > Alain
> >
> > 2012/7/20 Alain RODRIGUEZ :
> >> Hi Aaron,
> >>
> >> I have repaired and cleanup both nodes already and I did it after any
> >> change on my ring (It tooks me a while btw :)).
> >>
> >> The node *.211 is actually out of the ring and out of my control
> >> 'cause I don't have the server anymore (EC2 instance terminated a few
> >> days ago).
> >>
> >> Alain
> >>
> >> 2012/7/20 aaron morton :
> >>> I would:
> >>>
> >>> * run repair on 10.58.83.109
> >>> * run cleanup on 10.59.21.241 (I assume this was the first node).
> >>>
> >>> It looks like 0.56.62.211 is out of the cluster.
> >>>
> >>> Cheers
> >>>
> >>> -
> >>> Aaron Morton
> >>> Freelance Developer
> >>> @aaronmorton
> >>> http://www.thelastpickle.com
> >>>
> >>> On 19/07/2012, at 9:37 PM, Alain RODRIGUEZ wrote:
> >>>
> >>> Not sure if this may help :
> >>>
> >>> nodetool -h localhost gossipinfo
> >>> /10.58.83.109
> >>>  RELEASE_VERSION:1.1.2
> >>>  RACK:1b
> >>>  LOAD:5.9384978406E10
> >>>  SCHEMA:e7e0ec6c-616e-32e7-ae29-40eae2b82ca8
> >>>  DC:eu-west
> >>>  STATUS:NORMAL,85070591730234615865843651857942052864
> >>>  RPC_ADDRESS:0.0.0.0
> >>> /10.248.10.94
> >>>  RELEASE_VERSION:1.1.2
> >>>  LOAD:3.0128207422E10
> >>>  SCHEMA:e7e0ec6c-616e-32e7-ae29-40eae2b82ca8
> >>>  STATUS:LEFT,0,1342866804032
> >>>  RPC_ADDRESS:0.0.0.0
> >>> /10.56.62.211
> >>>  RELEASE_VERSION:1.1.2
> >>>  LOAD:11594.0
> >>>  RACK:1b
> >>>  SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
> >>>  DC:eu-west
> >>>  REMOVAL_COORDINATOR:REMOVER,85070591730234615865843651857942052864
> >>>  STATUS:removed,170141183460469231731687303715884105727,1342453967415
> >>>  RPC_ADDRESS:0.0.0.0
> >>> /10.59.21.241
> >>>  RELEASE_VERSION:1.1.2
> >>>  RACK:1b
> >>>  LOAD:1.08667047094E11
> >>>  SCHEMA:e7e0ec6c-616e-32e7-ae29-40eae2b82ca8
> >>>  DC:eu-west
> >>>  STATUS:NORMAL,0
> >>>  RPC_ADDRESS:0.0.0.0
> >>>
> >>> Story :
> >>>
> >>> I had 2 node cluster
> >>>
> >>> 10.248.10.94 Token 0
> >>> 10.59.21.241 Token 85070591730234615865843651857942052864
> >>>
> >>> Had to replace node 10.248.10.94 so I add 10.56.62.211 on token 0 - 1
> >>> (170141183460469231731687303715884105727). This failed, I removed
> >>> token.
> >>>
> >>> I repeat the previous operation with the node 10.59.21.241 and it went
> >>> fine. Next I decommissionned the node 10.248.10.94 and moved
> >>> 10.59.21.241 to the token 0.
> >>>
> >>> Now I am on the situation described before.
> >>>
> >>> Alain
> >>>
> >>>
> >>> 2012/7/19 Alain RODRIGUEZ :
> >>>
> >>> Hi, I wasn't able to see the token used currently by the 10.56.62.211
> >>>
> >>> (ghost node).
> >>>
> >>>
> >>> I already removed the token 6 days ago :
> >>>
> >>>
> >>> -> "Removing token 170141183460469231731687303715884105727 for
> >>> /10.56.62.211"
> >>>
> >>>
> >>> "- check in cassandra log. It is possible you see a log line telling
> >>>
> >>> you 10.56.62.211 and 10.59.21.241 o 10.58.83.109  share the same
> >>>
> >>> token"
> >>>
> >>>
> >>> Nothing like that in the logs
> >>>
> >>>
> >>> I tried the following without success :
> >>>
> >>>
> >>> $ nodetool -h localhost removetoken
> 170141183460469231731687303715884105727
> >>>
> >>> Exception in thread "main" java.lang.UnsupportedOperationException:
> >>>
> >>> Token not found.
> >>>
> >>> ...
> >>>
> >>>
> >>> I really thought this was going to work :-).
> >>>
> >>>
> >>> Any other ideas ?
> >>>
> >>>
> >>> Alain
> >>>
> >>>
> >>> PS : I heard that Octo is a nice company and you use Cassandra so I
> >>>
> >>> guess you're fine in there :-). I wish you the best thanks for your
> >>>
> >>> help.
> >>>
> >>>
> >>> 2012/7/19 Olivier Mallassi :
> >>>
> >>> I got that a couple of time (due to DNS issues in our infra)
> >>>
> >>>
> >>> what you could try
> >>>
> >>> - check in cassandra log

Re: Unreachable node, not in nodetool ring

[Alain RODRIGUEZ]

Hi again,

Nobody has a clue about this issue ?

I'm still facing this problem.

Alain

2012/7/23 Alain RODRIGUEZ :
> Does anyone knows how to totally remove a dead node that only appears
> when doing a "describe cluster" from the cli ?
>
> I still got this issue in my production cluster.
>
> Alain
>
> 2012/7/20 Alain RODRIGUEZ :
>> Hi Aaron,
>>
>> I have repaired and cleanup both nodes already and I did it after any
>> change on my ring (It tooks me a while btw :)).
>>
>> The node *.211 is actually out of the ring and out of my control
>> 'cause I don't have the server anymore (EC2 instance terminated a few
>> days ago).
>>
>> Alain
>>
>> 2012/7/20 aaron morton :
>>> I would:
>>>
>>> * run repair on 10.58.83.109
>>> * run cleanup on 10.59.21.241 (I assume this was the first node).
>>>
>>> It looks like 0.56.62.211 is out of the cluster.
>>>
>>> Cheers
>>>
>>> -
>>> Aaron Morton
>>> Freelance Developer
>>> @aaronmorton
>>> http://www.thelastpickle.com
>>>
>>> On 19/07/2012, at 9:37 PM, Alain RODRIGUEZ wrote:
>>>
>>> Not sure if this may help :
>>>
>>> nodetool -h localhost gossipinfo
>>> /10.58.83.109
>>>  RELEASE_VERSION:1.1.2
>>>  RACK:1b
>>>  LOAD:5.9384978406E10
>>>  SCHEMA:e7e0ec6c-616e-32e7-ae29-40eae2b82ca8
>>>  DC:eu-west
>>>  STATUS:NORMAL,85070591730234615865843651857942052864
>>>  RPC_ADDRESS:0.0.0.0
>>> /10.248.10.94
>>>  RELEASE_VERSION:1.1.2
>>>  LOAD:3.0128207422E10
>>>  SCHEMA:e7e0ec6c-616e-32e7-ae29-40eae2b82ca8
>>>  STATUS:LEFT,0,1342866804032
>>>  RPC_ADDRESS:0.0.0.0
>>> /10.56.62.211
>>>  RELEASE_VERSION:1.1.2
>>>  LOAD:11594.0
>>>  RACK:1b
>>>  SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
>>>  DC:eu-west
>>>  REMOVAL_COORDINATOR:REMOVER,85070591730234615865843651857942052864
>>>  STATUS:removed,170141183460469231731687303715884105727,1342453967415
>>>  RPC_ADDRESS:0.0.0.0
>>> /10.59.21.241
>>>  RELEASE_VERSION:1.1.2
>>>  RACK:1b
>>>  LOAD:1.08667047094E11
>>>  SCHEMA:e7e0ec6c-616e-32e7-ae29-40eae2b82ca8
>>>  DC:eu-west
>>>  STATUS:NORMAL,0
>>>  RPC_ADDRESS:0.0.0.0
>>>
>>> Story :
>>>
>>> I had 2 node cluster
>>>
>>> 10.248.10.94 Token 0
>>> 10.59.21.241 Token 85070591730234615865843651857942052864
>>>
>>> Had to replace node 10.248.10.94 so I add 10.56.62.211 on token 0 - 1
>>> (170141183460469231731687303715884105727). This failed, I removed
>>> token.
>>>
>>> I repeat the previous operation with the node 10.59.21.241 and it went
>>> fine. Next I decommissionned the node 10.248.10.94 and moved
>>> 10.59.21.241 to the token 0.
>>>
>>> Now I am on the situation described before.
>>>
>>> Alain
>>>
>>>
>>> 2012/7/19 Alain RODRIGUEZ :
>>>
>>> Hi, I wasn't able to see the token used currently by the 10.56.62.211
>>>
>>> (ghost node).
>>>
>>>
>>> I already removed the token 6 days ago :
>>>
>>>
>>> -> "Removing token 170141183460469231731687303715884105727 for
>>> /10.56.62.211"
>>>
>>>
>>> "- check in cassandra log. It is possible you see a log line telling
>>>
>>> you 10.56.62.211 and 10.59.21.241 o 10.58.83.109  share the same
>>>
>>> token"
>>>
>>>
>>> Nothing like that in the logs
>>>
>>>
>>> I tried the following without success :
>>>
>>>
>>> $ nodetool -h localhost removetoken 170141183460469231731687303715884105727
>>>
>>> Exception in thread "main" java.lang.UnsupportedOperationException:
>>>
>>> Token not found.
>>>
>>> ...
>>>
>>>
>>> I really thought this was going to work :-).
>>>
>>>
>>> Any other ideas ?
>>>
>>>
>>> Alain
>>>
>>>
>>> PS : I heard that Octo is a nice company and you use Cassandra so I
>>>
>>> guess you're fine in there :-). I wish you the best thanks for your
>>>
>>> help.
>>>
>>>
>>> 2012/7/19 Olivier Mallassi :
>>>
>>> I got that a couple of time (due to DNS issues in our infra)
>>>
>>>
>>> what you could try
>>>
>>> - check in cassandra log. It is possible you see a log line telling you
>>>
>>> 10.56.62.211 and 10.59.21.241 o 10.58.83.109  share the same token
>>>
>>> - if 10.56.62.211 is up, try decommission (via nodetool)
>>>
>>> - if not, move 10.59.21.241 or 10.58.83.109 to current token + 1
>>>
>>> - use removetoken (via nodetool) to remove the token associated with
>>>
>>> 10.56.62.211. in case of failure, you can use removetoken -f instead.
>>>
>>>
>>> then, the unreachable IP should have disappeared.
>>>
>>>
>>>
>>> HTH
>>>
>>>
>>> On Thu, Jul 19, 2012 at 10:38 AM, Alain RODRIGUEZ 
>>>
>>> wrote:
>>>
>>>
>>> Hi,
>>>
>>>
>>> I tried to add a node a few days ago and it failed. I finally made it
>>>
>>> work with an other node but now when I describe cluster on cli I got
>>>
>>> this :
>>>
>>>
>>> Cluster Information:
>>>
>>>   Snitch: org.apache.cassandra.locator.Ec2Snitch
>>>
>>>   Partitioner: org.apache.cassandra.dht.RandomPartitioner
>>>
>>>   Schema versions:
>>>
>>>  UNREACHABLE: [10.56.62.211]
>>>
>>>  e7e0ec6c-616e-32e7-ae29-40eae2b82ca8: [10.59.21.241, 10.58.83.109]
>>>
>>>
>>> And nodetool ring gives me :
>>>
>>>
>>> Address DC  RackStatus State   Load
>>>
>>> OwnsToken
>>>
>>>
>>

Re: Questions regarding DataStax AMI

[Tamar Fraenkel]

HI!
I tried starting a cluster with
Cluster started with these options:
--clustername  --totalnodes 3 --version community --release 1.0.8

But Cassandra's version is 1.1.2
Thanks

*Tamar Fraenkel *
Senior Software Engineer, TOK Media

[image: Inline image 1]

ta...@tok-media.com
Tel:   +972 2 6409736
Mob:  +972 54 8356490
Fax:   +972 2 5612956





On Thu, Jul 26, 2012 at 9:56 PM, Tamar Fraenkel  wrote:

> What should be the value to create it with Cassandra 1.0.8
> Tamar
>
> Sent from my iPod
>
> On Jul 26, 2012, at 7:06 PM, Joaquin Casares  wrote:
>
> Yes, you can easily do this by using the --release  switch as
> found here:
> http://www.datastax.com/docs/1.0/install/install_ami
>
> Thanks,
>
> Joaquin Casares
> DataStax
> Software Engineer/Support
>
>
>
> On Thu, Jul 26, 2012 at 12:44 AM, Tamar Fraenkel wrote:
>
>> Hi!
>> Is there a way to launch EC2 cluster from DataStax latest community AMI
>> that will run Cassandra 1.0.8 and not 1.1.2?
>> Thanks
>>  *Tamar Fraenkel *
>> Senior Software Engineer, TOK Media
>>
>> 
>>
>>
>> ta...@tok-media.com
>> Tel:   +972 2 6409736
>> Mob:  +972 54 8356490
>> Fax:   +972 2 5612956
>>
>>
>>
>>
>>
>
<>

Re: Schema question : Query to support "Find which all of these 500 email ids have been registered"

[Aklin_81]

What about if I spread these columns across 20 rows ? Then I have to
query each of these 20 rows for 500 columns. but still this seems a
better solution than one row for all cols or separate row for each
email id approaches !?

On Fri, Jul 27, 2012 at 11:36 AM, Aklin_81  wrote:
> Sorry for the confusion created. I need to store emails registered
> just for a single application. So although my data model would fit
> into just a single row. But is storing a hundred million  columns(col
> name size= 8 byte; col value size=4 byte ) in a single row a good idea
> ? I am very much tempted to store it in single row but I also heard it
> is recommended to keep a row size within 10s of MBs for optimal
> performance.

Re: restoring a counter

[Sylvain Lebresne]

>>>   a) how does that setting affect C* in a non-restoring start?
>
> renew_counter_id regenerates a new "NodeId" for the cassandra VM which
> is used to keep track of the counter shards the node holds. If you
> regenerate node ids on each restart, you will most likely corrupt your
> counter data.

The description of NodeId is correct but the part about regenerating
it could lead to counter data corruption is not. There is no risk of
corrupting counter by regenerating the node id too often (or at least
there should not be), but it does have an impact on performance.
Basically, if you restart with the -Dcassandra.renew_counter_id=true,
the internal representation for your counter will become bigger (the
size occupied on disk, not the counter value itself) over time. And by
over time I mean, with new counter increment coming in. So if you
restart even a few times with the flag on over a short period of time,
it's fine, it won't have much negative impact, but in general it is a
one shot flag and you should not leave it on.

>>>   b) if it's < bad > (for some value of that), should I stop C*+remove
>>> the setting+start C* after the value has been repaired?

The short answer is no. The renewal of the node id that the flag
trigger is done at startup and once it's done, it's done. When you
start with the flag on, the only thing you want to make sure is to not
have the flag on for the next restart, but there is no reason to force
that restart.

--
Sylvain

Re: is it possible to disable compaction per CF ?

[Jason Tang]

setMaxCompactionThreshold(0)
setMinCompactionThreshold(0)

2012/7/27 Илья Шипицин 

> Hello!
>
> if we are dealing with append-only data model, so what if I disable
> compaction on certain CF ?
> any side effect ?
>
> can I do it with
>
> "update column family  with compaction_strategy = null " ?
>
> Cheers,
> Ilya Shipitsin
>