Re: Node crashes on repair (Cassandra 3.11.1)

Christian, I'm not an expert, but maybe the merkle tree is too big to transfer between nodes and that's why it times out. How many nodes do you have and what's the size of the keyspace? Have you ever done a successfully repair before? Cassandra reaper does repair based on tokenrange (or even

Re: Best approach to prepare to shutdown a cassandra node

icsson.com>> wrote: > >> > >> Looking at the code in trunk, the stopdemon command invokes the > >> CassandraDaemon.stop() function which does a graceful shutdown by > >> stopping jmxServer and drains the node by the shutdown hook. > >>

Re: Best approach to prepare to shutdown a cassandra node

As far as I know, the nodetool stopdaemon is doing a "kill -9". Or did it change? 2017-10-12 23:49 GMT-03:00 Anshu Vajpayee <anshu.vajpa...@gmail.com>: > Why are you killing when we have nodetool stopdaemon ? > > On Fri, Oct 13, 2017 at 1:49 AM, Javier Canillas <

Re: Best approach to prepare to shutdown a cassandra node

That's what I thought. Thanks! 2017-10-12 14:26 GMT-03:00 Hannu Kröger <hkro...@gmail.com>: > Hi, > > Drain should be enough. It stops accepting writes and after that > cassandra can be safely shut down. > > Hannu > > On 12 October 2017 at 20:24:41, Javier Canil

Best approach to prepare to shutdown a cassandra node

Hello everyone, I have some time working with Cassandra, but every time I need to shutdown a node (for any reason like upgrading version or moving instance to another host) I see several errors on the client applications (yes, I'm using the official java driver). By the way, I'm starting C* as a

Re: LWT and non-LWT mixed

Daniel, Cassandra is "eventually consistent". This means that the DELETE can go to a different coordinator than the INSERT... IF NOT EXISTS. Being so, each coordinator enters a race condition than can make the INSERT...IF NOT EXISTS failed reading data that the DELETE will destroy. Even on the

Re: table repair question

dary consideration. The important thing is to repair > data more frequently than your gc grace period. > > > On October 4, 2017 at 1:33:57 PM, Javier Canillas ( > javier.canil...@gmail.com) wrote: > > That percentage will only be updated if you do a full repair. If you do > repair

Re: CREATE INDEX without IF NOT EXISTS when snapshoting

Well, Patches submitted for version 3.0, 3.11 and trunk (although 3.0 patch can be applied to 3.11). Feel free to review and comment. Thanks! 2017-10-04 16:41 GMT-03:00 Javier Canillas <javier.canil...@gmail.com>: > Kurt, > > Thanks for your response. Created this

Re: table repair question

That percentage will only be updated if you do a full repair. If you do repairs on local dc or with -pr, that percentage will not be updated. I scripted a regular repair on each node based on if this percentage is below some threshold. It has been running fine since several months ago.

Re: CREATE INDEX without IF NOT EXISTS when snapshoting

Kurt, Thanks for your response. Created this ticket . Feel free to add anything to it that seems legit. Downloading Cassandra code right now. Fix seems quite simple. Expect a pull-request soon xD 2017-10-03 20:19 GMT-03:00 kurt greaves

CREATE INDEX without IF NOT EXISTS when snapshoting

Hi everyone, I came across something that bothers me a lot. I'm using snapshots to backup data from my Cassandra cluster in case something really bad happens (like dropping a table or a keyspace). Exercising the recovery actions from those backups, I discover that the schema put on the file

Re: Repairing question

ired since this require > >> anti-compaction to be run. > >> > >> Actually this "percent repaired" display name is a bit misleading, > >> since it sounds like data needs to be repaired while you could be > >> running non-incremental rep

Re: Repairing question

ntal repairs and still have data 100% repaired, so > we should probably open a ticket to rename that to "Percent > incrementally repaired" or similar. > > > 2017-06-22 14:38 GMT-05:00 Javier Canillas <javier.canil...@gmail.com>: > > Hi, > > > > I have

Repairing question

Hi, I have been thinking about scheduling a daily routine to force repairs on a cluster to maintain its health. I saw that by running a nodetool tablestats [keyspace] there is an attribute called "Percent repaired" that show the percentage of data repaired on the each table. This attribute

Cassandra Driver Configurer

Hey guys, I have following Cassandra since its preliminar 0,6.X versions and develop against it from different platforms like .NET, Java and Scala. I found it very difficult to properly configure my cassandra driver for the client application since there is no straight way to change a value

Re: UnavailableException with 1 node down and RF=2?

What the problem might be is that you are setting the Consistency Level to a value bigger than 1. In such cases, Cassandra will respond you with an UnavailableException since it can't achieve the level of consistency you are asking for. Remember that, when you have RF=2, CS values as ALL and

Re: Columns values(integer) need frequent updates/ increments

By comparing timestamp. The highest value is supposed to be the most updated Sent from my iPhone On 09/04/2011, at 21:02, mcasandra mohitanch...@gmail.com wrote: If there are multiple updates to same columns and scattered accross multiple sstables then how does cassandra know which sstable

Re: Understanding Indexes

I dont think i got the point in your question. But if you are thinking about key indexes (like PKs), take in mind that cassandra will manage keys using the partition strategy. By doing so, it will be able to determine on which node the row with such key should be hold. So, in another words, inside

Re: Understand eventually consistent

First of all, in your example W=CL? If it so, then the success of any read / write operarion will be determine by if the CL required can be satisfied in that moment. If you write with CL ONE over a CF with RF 3 when 1 node of the replicas is down, then the operarion will success and HitedHandOff

Re: Understanding Indexes

I really don't see the point.. Again, suppose a cluster with 3 nodes, where there is a ColumnFamily that will hold data which key is basically consisted on a word of 2 letters (pretty simple). That's make a total of 729 posible keys. RandomPartitioner then will tokenize each key and assign them

Re: Understand eventually consistent

be sure to write on 2 at least. In cases where RF is 1 or 2, then QUORUM is like ALL (be sure to write on all nodes involved). On Thu, Feb 24, 2011 at 3:29 PM, mcasandra mohitanch...@gmail.com wrote: Javier Canillas wrote: Instead, when you execute the same OP using CL QUORUM, then it means

Re: Understanding Indexes

I don't say you shouldn't. In case you feel like there is a problem, you may think of splitting column families into N. But I think you won't get that problem. You can read about RowCacheSize and KeyCache support on 0.7.X of Cassandra, if you rows are small, you may cache a lot of them and avoid a

Re: Understand eventually consistent

HH is some kind of write repair, so it has nothing to do with CL that is a requirement of the operation; and it won't be used over reads. In your example QUORUM is the same as ALL, since you only have 1 RF (only the data holder - coordinator). If that node fails, all read / writes will fail.

Re: Understand eventually consistent

...@gmail.com wrote: Javier Canillas wrote: HH is some kind of write repair, so it has nothing to do with CL that is a requirement of the operation; and it won't be used over reads. In your example QUORUM is the same as ALL, since you only have 1 RF (only the data holder

Re: Timeout

Why don't you post some details about your Cassandra Cluster, version, information about the keyspace you are creating (for example which is the replication factor within)? It might be of help. Besides, I don't fully understand your code. First you drop KEYSPACE, then create it again with a

Re: What is the most solid version of Cassandra? No secondary indexes needed.

after some heavy stress test, it will give you a better migration process to any new version. Javier Canillas On Tue, Feb 15, 2011 at 5:03 PM, buddhasystem potek...@bnl.gov wrote: Thank you! It's just that 7.1 seems the bleeding edge now (a serious bug fixed today). Would you still trust

Re: Indexes and hard disk

. Hope this information is useful to you Regards, Javier canillas El 12/02/2011, a las 04:24, mcasandra mohitanch...@gmail.com escribió: Are indexes supported in Cassandra? If yes then what kind? Also, if it's supported then please point me to the place that give more information about

Re: Compression in Cassandra

How do you calculate your 40g data? When you insert it into Cassandra, you need to convert the data into a Byte[], maybe your problem is there. On Thu, Jan 20, 2011 at 10:02 AM, akshatbakli...@gmail.com akshatbakli...@gmail.com wrote: Hi all, I am experiencing a unique situation. I loaded

Re: can't re-insert row after deleting it?

As Jonathan has told you, Please double check the Timestamp of the column you are adding the second time. Probably this timestamp is smaller (or lowerer) than the timestamp given when the deletion happens. On Thu, Dec 30, 2010 at 1:27 AM, Jonathan Ellis jbel...@gmail.com wrote: deletes win