multiple Datacenter values in PropertyFileSnitch
Hi, I would like to create big cluster for many applications. Within this cluster I would like to separate the data for each application, which can be easily done via different virtual datacenters and the correct replication strategy. What I would like to know, if I can specify for 1 node multiple values in the PropertyFileSnitch configuration, so that I can use 1 node for more applications? For example: 6 nodes: 3 for App A 3 for App B 4 for App C I want to have such a configuration: Node 1 - DC-A DC-C Node 2 - DC-B DC-C Node 3 - DC-A DC-C Node 4 - DC-B DC-C Node 5 - DC-A Node 6 - DC-B Is this possible or does anyone have another solution for this? Thx br matthias
RE: multiple Datacenter values in PropertyFileSnitch
I´m using for each application it´s own keyspace. What I want is to split up for different load patterns. So that 2 apps with same and very high load pattern are not clashing. For other load patterns I want to use another splitting. Is there any best practice or should I scale out, so that the complete load can be distributed to on all nodes? Br, Matthias Zeilinger Production Operation - Shared Services P: +43 (0) 50 858-31185 M: +43 (0) 664 85-34459 E: matthias.zeilin...@bwinparty.com bwin.party services (Austria) GmbH Marxergasse 1B A-1030 Vienna www.bwinparty.com From: aaron morton [mailto:aa...@thelastpickle.com] Sent: Donnerstag, 11. April 2013 20:48 To: user@cassandra.apache.org Subject: Re: multiple Datacenter values in PropertyFileSnitch A node can only exist in one DC and one rack. Use different keyspaces as suggested. Cheers - Aaron Morton Freelance Cassandra Consultant New Zealand @aaronmorton http://www.thelastpickle.com On 12/04/2013, at 1:47 AM, Jabbar Azam aja...@gmail.commailto:aja...@gmail.com wrote: Hello, I'm not an expert but I don't think you can do what you want. The way to separate data for applications on the same cluster is to use different tables for different applications or use multiple keyspaces, a keyspace per application. The replication factor you specify for each keyspace specifies how many copies of the data are stored in each datacenter. You can't specify that data for a particular application is stored on a specific node, unless that node is in its own cluster. I think of a cassandra cluster as a shared resource where all the applications have access to all the nodes in the cluster. Thanks Jabbar Azam On 11 April 2013 14:13, Matthias Zeilinger matthias.zeilin...@bwinparty.commailto:matthias.zeilin...@bwinparty.com wrote: Hi, I would like to create big cluster for many applications. Within this cluster I would like to separate the data for each application, which can be easily done via different virtual datacenters and the correct replication strategy. What I would like to know, if I can specify for 1 node multiple values in the PropertyFileSnitch configuration, so that I can use 1 node for more applications? For example: 6 nodes: 3 for App A 3 for App B 4 for App C I want to have such a configuration: Node 1 - DC-A DC-C Node 2 - DC-B DC-C Node 3 - DC-A DC-C Node 4 - DC-B DC-C Node 5 - DC-A Node 6 - DC-B Is this possible or does anyone have another solution for this? Thx br matthias
RE: old data / tombstones are not deleted after ttl
Short question afterwards: I have read in the documentation, that after a major compaction, minor compactions are no longer automatically trigger. Does this mean, that I have to do the nodetool compact regulary? Or is there a way to get back to the automatically minor compactions? Thx, Br, Matthias Zeilinger Production Operation – Shared Services P: +43 (0) 50 858-31185 M: +43 (0) 664 85-34459 E: matthias.zeilin...@bwinparty.com bwin.party services (Austria) GmbH Marxergasse 1B A-1030 Vienna www.bwinparty.com -Original Message- From: Matthias Zeilinger [mailto:matthias.zeilin...@bwinparty.com] Sent: Dienstag, 05. März 2013 08:03 To: user@cassandra.apache.org Subject: RE: old data / tombstones are not deleted after ttl Yes it was a major compaction. I know it´s not a great solution, but I needed something to get rid of the old data, because I went out of diskspace. Br, Matthias Zeilinger Production Operation – Shared Services P: +43 (0) 50 858-31185 M: +43 (0) 664 85-34459 E: matthias.zeilin...@bwinparty.com bwin.party services (Austria) GmbH Marxergasse 1B A-1030 Vienna www.bwinparty.com -Original Message- From: Michal Michalski [mailto:mich...@opera.com] Sent: Dienstag, 05. März 2013 07:47 To: user@cassandra.apache.org Subject: Re: old data / tombstones are not deleted after ttl Was it a major compaction? I ask because it's definitely a solution that had to work, but it's also a solution that - in general - probably no-one here would suggest you to use. M. W dniu 05.03.2013 07:08, Matthias Zeilinger pisze: Hi, I have done a manually compaction over the nodetool and this worked. But thx for the explanation, why it wasn´t compacted Br, Matthias Zeilinger Production Operation – Shared Services P: +43 (0) 50 858-31185 M: +43 (0) 664 85-34459 E: matthias.zeilin...@bwinparty.com bwin.party services (Austria) GmbH Marxergasse 1B A-1030 Vienna www.bwinparty.com From: Bryan Talbot [mailto:btal...@aeriagames.com] Sent: Montag, 04. März 2013 23:36 To: user@cassandra.apache.org Subject: Re: old data / tombstones are not deleted after ttl Those older files won't be included in a compaction until there are min_compaction_threshold (4) files of that size. When you get another SS table -Data.db file that is about 12-18GB then you'll have 4 and they will be compacted together into one new file. At that time, if there are any rows with only tombstones that are all older than gc_grace the row will be removed (assuming the row exists exclusively in the 4 input SS tables). Columns with data that is more than TTL seconds old will be written with a tombstone. If the row does have column values in SS tables that are not being compacted, the row will not be removed. -Bryan On Sun, Mar 3, 2013 at 11:07 PM, Matthias Zeilinger matthias.zeilin...@bwinparty.commailto:matthias.zeilin...@bwinparty.com wrote: Hi, I´m running Cassandra 1.1.5 and have following issue. I´m using a 10 days TTL on my CF. I can see a lot of tombstones in there, but they aren´t deleted after compaction. I have tried a nodetool –cleanup and also a restart of Cassandra, but nothing happened. total 61G drwxr-xr-x 2 cassandra dba 20K Mar 4 06:35 . drwxr-xr-x 10 cassandra dba 4.0K Dec 10 13:05 .. -rw-r--r-- 1 cassandra dba 15M Dec 15 22:04 whatever-he-1398-CompressionInfo.db -rw-r--r-- 1 cassandra dba 19G Dec 15 22:04 whatever-he-1398-Data.db -rw-r--r-- 1 cassandra dba 15M Dec 15 22:04 whatever-he-1398-Filter.db -rw-r--r-- 1 cassandra dba 357M Dec 15 22:04 whatever-he-1398-Index.db -rw-r--r-- 1 cassandra dba 4.3K Dec 15 22:04 whatever-he-1398-Statistics.db -rw-r--r-- 1 cassandra dba 9.5M Feb 6 15:45 whatever-he-5464-CompressionInfo.db -rw-r--r-- 1 cassandra dba 12G Feb 6 15:45 whatever-he-5464-Data.db -rw-r--r-- 1 cassandra dba 48M Feb 6 15:45 whatever-he-5464-Filter.db -rw-r--r-- 1 cassandra dba 736M Feb 6 15:45 whatever-he-5464-Index.db -rw-r--r-- 1 cassandra dba 4.3K Feb 6 15:45 whatever-he-5464-Statistics.db -rw-r--r-- 1 cassandra dba 9.7M Feb 21 19:13 whatever-he-6829-CompressionInfo.db -rw-r--r-- 1 cassandra dba 12G Feb 21 19:13 whatever-he-6829-Data.db -rw-r--r-- 1 cassandra dba 47M Feb 21 19:13 whatever-he-6829-Filter.db -rw-r--r-- 1 cassandra dba 792M Feb 21 19:13 whatever-he-6829-Index.db -rw-r--r-- 1 cassandra dba 4.3K Feb 21 19:13 whatever-he-6829-Statistics.db -rw-r--r-- 1 cassandra dba 3.7M Mar 1 10:46 whatever-he-7578-CompressionInfo.db -rw-r--r-- 1 cassandra dba 4.3G Mar 1 10:46 whatever-he-7578-Data.db -rw-r--r-- 1 cassandra dba 12M Mar 1 10:46 whatever-he-7578-Filter.db -rw-r--r-- 1 cassandra dba 274M Mar 1 10:46 whatever-he-7578-Index.db -rw-r--r-- 1 cassandra dba 4.3K Mar 1 10:46 whatever-he-7578-Statistics.db -rw-r--r-- 1 cassandra dba 3.6M Mar 1 11:21 whatever-he-7582-CompressionInfo.db -rw-r--r-- 1 cassandra dba 4.3G Mar 1 11:21
RE: old data / tombstones are not deleted after ttl
Hi, I have done a manually compaction over the nodetool and this worked. But thx for the explanation, why it wasn´t compacted Br, Matthias Zeilinger Production Operation – Shared Services P: +43 (0) 50 858-31185 M: +43 (0) 664 85-34459 E: matthias.zeilin...@bwinparty.com bwin.party services (Austria) GmbH Marxergasse 1B A-1030 Vienna www.bwinparty.com From: Bryan Talbot [mailto:btal...@aeriagames.com] Sent: Montag, 04. März 2013 23:36 To: user@cassandra.apache.org Subject: Re: old data / tombstones are not deleted after ttl Those older files won't be included in a compaction until there are min_compaction_threshold (4) files of that size. When you get another SS table -Data.db file that is about 12-18GB then you'll have 4 and they will be compacted together into one new file. At that time, if there are any rows with only tombstones that are all older than gc_grace the row will be removed (assuming the row exists exclusively in the 4 input SS tables). Columns with data that is more than TTL seconds old will be written with a tombstone. If the row does have column values in SS tables that are not being compacted, the row will not be removed. -Bryan On Sun, Mar 3, 2013 at 11:07 PM, Matthias Zeilinger matthias.zeilin...@bwinparty.commailto:matthias.zeilin...@bwinparty.com wrote: Hi, I´m running Cassandra 1.1.5 and have following issue. I´m using a 10 days TTL on my CF. I can see a lot of tombstones in there, but they aren´t deleted after compaction. I have tried a nodetool –cleanup and also a restart of Cassandra, but nothing happened. total 61G drwxr-xr-x 2 cassandra dba 20K Mar 4 06:35 . drwxr-xr-x 10 cassandra dba 4.0K Dec 10 13:05 .. -rw-r--r-- 1 cassandra dba 15M Dec 15 22:04 whatever-he-1398-CompressionInfo.db -rw-r--r-- 1 cassandra dba 19G Dec 15 22:04 whatever-he-1398-Data.db -rw-r--r-- 1 cassandra dba 15M Dec 15 22:04 whatever-he-1398-Filter.db -rw-r--r-- 1 cassandra dba 357M Dec 15 22:04 whatever-he-1398-Index.db -rw-r--r-- 1 cassandra dba 4.3K Dec 15 22:04 whatever-he-1398-Statistics.db -rw-r--r-- 1 cassandra dba 9.5M Feb 6 15:45 whatever-he-5464-CompressionInfo.db -rw-r--r-- 1 cassandra dba 12G Feb 6 15:45 whatever-he-5464-Data.db -rw-r--r-- 1 cassandra dba 48M Feb 6 15:45 whatever-he-5464-Filter.db -rw-r--r-- 1 cassandra dba 736M Feb 6 15:45 whatever-he-5464-Index.db -rw-r--r-- 1 cassandra dba 4.3K Feb 6 15:45 whatever-he-5464-Statistics.db -rw-r--r-- 1 cassandra dba 9.7M Feb 21 19:13 whatever-he-6829-CompressionInfo.db -rw-r--r-- 1 cassandra dba 12G Feb 21 19:13 whatever-he-6829-Data.db -rw-r--r-- 1 cassandra dba 47M Feb 21 19:13 whatever-he-6829-Filter.db -rw-r--r-- 1 cassandra dba 792M Feb 21 19:13 whatever-he-6829-Index.db -rw-r--r-- 1 cassandra dba 4.3K Feb 21 19:13 whatever-he-6829-Statistics.db -rw-r--r-- 1 cassandra dba 3.7M Mar 1 10:46 whatever-he-7578-CompressionInfo.db -rw-r--r-- 1 cassandra dba 4.3G Mar 1 10:46 whatever-he-7578-Data.db -rw-r--r-- 1 cassandra dba 12M Mar 1 10:46 whatever-he-7578-Filter.db -rw-r--r-- 1 cassandra dba 274M Mar 1 10:46 whatever-he-7578-Index.db -rw-r--r-- 1 cassandra dba 4.3K Mar 1 10:46 whatever-he-7578-Statistics.db -rw-r--r-- 1 cassandra dba 3.6M Mar 1 11:21 whatever-he-7582-CompressionInfo.db -rw-r--r-- 1 cassandra dba 4.3G Mar 1 11:21 whatever-he-7582-Data.db -rw-r--r-- 1 cassandra dba 9.7M Mar 1 11:21 whatever-he-7582-Filter.db -rw-r--r-- 1 cassandra dba 236M Mar 1 11:21 whatever-he-7582-Index.db -rw-r--r-- 1 cassandra dba 4.3K Mar 1 11:21 whatever-he-7582-Statistics.db -rw-r--r-- 1 cassandra dba 3.7M Mar 3 12:13 whatever-he-7869-CompressionInfo.db -rw-r--r-- 1 cassandra dba 4.3G Mar 3 12:13 whatever-he-7869-Data.db -rw-r--r-- 1 cassandra dba 9.8M Mar 3 12:13 whatever-he-7869-Filter.db -rw-r--r-- 1 cassandra dba 239M Mar 3 12:13 whatever-he-7869-Index.db -rw-r--r-- 1 cassandra dba 4.3K Mar 3 12:13 whatever-he-7869-Statistics.db -rw-r--r-- 1 cassandra dba 924K Mar 3 18:02 whatever-he-7953-CompressionInfo.db -rw-r--r-- 1 cassandra dba 1.1G Mar 3 18:02 whatever-he-7953-Data.db -rw-r--r-- 1 cassandra dba 2.1M Mar 3 18:02 whatever-he-7953-Filter.db -rw-r--r-- 1 cassandra dba 51M Mar 3 18:02 whatever-he-7953-Index.db -rw-r--r-- 1 cassandra dba 4.3K Mar 3 18:02 whatever-he-7953-Statistics.db -rw-r--r-- 1 cassandra dba 231K Mar 3 20:06 whatever-he-7974-CompressionInfo.db -rw-r--r-- 1 cassandra dba 268M Mar 3 20:06 whatever-he-7974-Data.db -rw-r--r-- 1 cassandra dba 483K Mar 3 20:06 whatever-he-7974-Filter.db -rw-r--r-- 1 cassandra dba 12M Mar 3 20:06 whatever-he-7974-Index.db -rw-r--r-- 1 cassandra dba 4.3K Mar 3 20:06 whatever-he-7974-Statistics.db -rw-r--r-- 1 cassandra dba 116K Mar 4 06:28 whatever-he-8002-CompressionInfo.db -rw-r--r-- 1 cassandra dba 146M Mar 4 06:28 whatever-he-8002-Data.db -rw-r--r-- 1 cassandra dba 646K Mar 4 06:28 whatever-he-8002-Filter.db -rw-r--r-- 1 cassandra dba 16M Mar 4 06:28 whatever-he-8002
RE: old data / tombstones are not deleted after ttl
Yes it was a major compaction. I know it´s not a great solution, but I needed something to get rid of the old data, because I went out of diskspace. Br, Matthias Zeilinger Production Operation – Shared Services P: +43 (0) 50 858-31185 M: +43 (0) 664 85-34459 E: matthias.zeilin...@bwinparty.com bwin.party services (Austria) GmbH Marxergasse 1B A-1030 Vienna www.bwinparty.com -Original Message- From: Michal Michalski [mailto:mich...@opera.com] Sent: Dienstag, 05. März 2013 07:47 To: user@cassandra.apache.org Subject: Re: old data / tombstones are not deleted after ttl Was it a major compaction? I ask because it's definitely a solution that had to work, but it's also a solution that - in general - probably no-one here would suggest you to use. M. W dniu 05.03.2013 07:08, Matthias Zeilinger pisze: Hi, I have done a manually compaction over the nodetool and this worked. But thx for the explanation, why it wasn´t compacted Br, Matthias Zeilinger Production Operation – Shared Services P: +43 (0) 50 858-31185 M: +43 (0) 664 85-34459 E: matthias.zeilin...@bwinparty.com bwin.party services (Austria) GmbH Marxergasse 1B A-1030 Vienna www.bwinparty.com From: Bryan Talbot [mailto:btal...@aeriagames.com] Sent: Montag, 04. März 2013 23:36 To: user@cassandra.apache.org Subject: Re: old data / tombstones are not deleted after ttl Those older files won't be included in a compaction until there are min_compaction_threshold (4) files of that size. When you get another SS table -Data.db file that is about 12-18GB then you'll have 4 and they will be compacted together into one new file. At that time, if there are any rows with only tombstones that are all older than gc_grace the row will be removed (assuming the row exists exclusively in the 4 input SS tables). Columns with data that is more than TTL seconds old will be written with a tombstone. If the row does have column values in SS tables that are not being compacted, the row will not be removed. -Bryan On Sun, Mar 3, 2013 at 11:07 PM, Matthias Zeilinger matthias.zeilin...@bwinparty.commailto:matthias.zeilin...@bwinparty.com wrote: Hi, I´m running Cassandra 1.1.5 and have following issue. I´m using a 10 days TTL on my CF. I can see a lot of tombstones in there, but they aren´t deleted after compaction. I have tried a nodetool –cleanup and also a restart of Cassandra, but nothing happened. total 61G drwxr-xr-x 2 cassandra dba 20K Mar 4 06:35 . drwxr-xr-x 10 cassandra dba 4.0K Dec 10 13:05 .. -rw-r--r-- 1 cassandra dba 15M Dec 15 22:04 whatever-he-1398-CompressionInfo.db -rw-r--r-- 1 cassandra dba 19G Dec 15 22:04 whatever-he-1398-Data.db -rw-r--r-- 1 cassandra dba 15M Dec 15 22:04 whatever-he-1398-Filter.db -rw-r--r-- 1 cassandra dba 357M Dec 15 22:04 whatever-he-1398-Index.db -rw-r--r-- 1 cassandra dba 4.3K Dec 15 22:04 whatever-he-1398-Statistics.db -rw-r--r-- 1 cassandra dba 9.5M Feb 6 15:45 whatever-he-5464-CompressionInfo.db -rw-r--r-- 1 cassandra dba 12G Feb 6 15:45 whatever-he-5464-Data.db -rw-r--r-- 1 cassandra dba 48M Feb 6 15:45 whatever-he-5464-Filter.db -rw-r--r-- 1 cassandra dba 736M Feb 6 15:45 whatever-he-5464-Index.db -rw-r--r-- 1 cassandra dba 4.3K Feb 6 15:45 whatever-he-5464-Statistics.db -rw-r--r-- 1 cassandra dba 9.7M Feb 21 19:13 whatever-he-6829-CompressionInfo.db -rw-r--r-- 1 cassandra dba 12G Feb 21 19:13 whatever-he-6829-Data.db -rw-r--r-- 1 cassandra dba 47M Feb 21 19:13 whatever-he-6829-Filter.db -rw-r--r-- 1 cassandra dba 792M Feb 21 19:13 whatever-he-6829-Index.db -rw-r--r-- 1 cassandra dba 4.3K Feb 21 19:13 whatever-he-6829-Statistics.db -rw-r--r-- 1 cassandra dba 3.7M Mar 1 10:46 whatever-he-7578-CompressionInfo.db -rw-r--r-- 1 cassandra dba 4.3G Mar 1 10:46 whatever-he-7578-Data.db -rw-r--r-- 1 cassandra dba 12M Mar 1 10:46 whatever-he-7578-Filter.db -rw-r--r-- 1 cassandra dba 274M Mar 1 10:46 whatever-he-7578-Index.db -rw-r--r-- 1 cassandra dba 4.3K Mar 1 10:46 whatever-he-7578-Statistics.db -rw-r--r-- 1 cassandra dba 3.6M Mar 1 11:21 whatever-he-7582-CompressionInfo.db -rw-r--r-- 1 cassandra dba 4.3G Mar 1 11:21 whatever-he-7582-Data.db -rw-r--r-- 1 cassandra dba 9.7M Mar 1 11:21 whatever-he-7582-Filter.db -rw-r--r-- 1 cassandra dba 236M Mar 1 11:21 whatever-he-7582-Index.db -rw-r--r-- 1 cassandra dba 4.3K Mar 1 11:21 whatever-he-7582-Statistics.db -rw-r--r-- 1 cassandra dba 3.7M Mar 3 12:13 whatever-he-7869-CompressionInfo.db -rw-r--r-- 1 cassandra dba 4.3G Mar 3 12:13 whatever-he-7869-Data.db -rw-r--r-- 1 cassandra dba 9.8M Mar 3 12:13 whatever-he-7869-Filter.db -rw-r--r-- 1 cassandra dba 239M Mar 3 12:13 whatever-he-7869-Index.db -rw-r--r-- 1 cassandra dba 4.3K Mar 3 12:13 whatever-he-7869-Statistics.db -rw-r--r-- 1 cassandra dba 924K Mar 3 18:02 whatever-he-7953-CompressionInfo.db -rw-r--r-- 1 cassandra dba 1.1G Mar 3 18:02 whatever-he
old data / tombstones are not deleted after ttl
6.7M Mar 4 06:35 whatever-he-8006-Data.db
-rw-r--r-- 1 cassandra dba 81K Mar 4 06:35 whatever-he-8006-Filter.db
-rw-r--r-- 1 cassandra dba 2.0M Mar 4 06:35 whatever-he-8006-Index.db
-rw-r--r-- 1 cassandra dba 4.3K Mar 4 06:35 whatever-he-8006-Statistics.db
The things marked in red, I guess, are the old data, but they aren´t deleted.
As you can see on the date, they are older than 10 days.
Is there any possibility to delete them?
Here is also the schema of the CF:
create column family whatever
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'AsciiType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.0
and dclocal_read_repair_chance = 0.0
and gc_grace = 0
and min_compaction_threshold = 4
and max_compaction_threshold = 32
and replicate_on_write = false
and compaction_strategy =
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
and caching = 'KEYS_ONLY'
and compression_options = {'sstable_compression' :
'org.apache.cassandra.io.compress.SnappyCompressor'};
Br,
Matthias Zeilinger
Production Operation - Shared Services
P: +43 (0) 50 858-31185
M: +43 (0) 664 85-34459
E: matthias.zeilin...@bwinparty.com
bwin.party services (Austria) GmbH
Marxergasse 1B
A-1030 Vienna
www.bwinparty.com
RE: data not shown up after some time
Hi, Thx for the great support. I have checked everything and after a rebuild_index all data were searchable. I will upgrade to 1.1.9 asap. Many thx, Br, Matthias Zeilinger Production Operation - Shared Services P: +43 (0) 50 858-31185 M: +43 (0) 664 85-34459 E: matthias.zeilin...@bwinparty.com bwin.party services (Austria) GmbH Marxergasse 1B A-1030 Vienna www.bwinparty.com -Original Message- From: aaron morton [mailto:aa...@thelastpickle.com] Sent: Dienstag, 29. Jänner 2013 21:51 To: user@cassandra.apache.org Subject: Re: data not shown up after some time How can I check for this secondary index read fails? Your description was that reads which use a secondary index (not the row key) failed. if I do a simple list cf; the data is shown, but it I do a get cf where index='testvalue'; If you can retrieve the row using it's row key, but not via the secondary index (index in your example) then the index is broken. If you are on pre 1.1.9 try upgrading. cheers - Aaron Morton Freelance Cassandra Developer New Zealand @aaronmorton http://www.thelastpickle.com On 29/01/2013, at 8:19 PM, Matthias Zeilinger matthias.zeilin...@bwinparty.com wrote: How can I check for this secondary index read fails? Is it in the system.log or over the nodetool? Br, Matthias Zeilinger Production Operation - Shared Services P: +43 (0) 50 858-31185 M: +43 (0) 664 85-34459 E: matthias.zeilin...@bwinparty.com bwin.party services (Austria) GmbH Marxergasse 1B A-1030 Vienna www.bwinparty.com From: aaron morton [mailto:aa...@thelastpickle.com] Sent: Dienstag, 29. Jänner 2013 08:04 To: user@cassandra.apache.org Subject: Re: data not shown up after some time If you are seeing failed secondary index reads you may be seeing this https://issues.apache.org/jira/browse/CASSANDRA-5079 Cheers - Aaron Morton Freelance Cassandra Developer New Zealand @aaronmorton http://www.thelastpickle.com On 29/01/2013, at 3:31 AM, Matthias Zeilinger matthias.zeilin...@bwinparty.com wrote: Hi, No I have checked the TTL: 7776000 Very interesting is, if I do a simple list cf; the data is shown, but it I do a get cf where index='testvalue'; it returns 0 Row Returned. How can that be? Br, Matthias Zeilinger Production Operation - Shared Services P: +43 (0) 50 858-31185 M: +43 (0) 664 85-34459 E: matthias.zeilin...@bwinparty.com bwin.party services (Austria) GmbH Marxergasse 1B A-1030 Vienna www.bwinparty.com From: Viktor Jevdokimov [mailto:viktor.jevdoki...@adform.com] Sent: Montag, 28. Jänner 2013 15:25 To: user@cassandra.apache.org Subject: RE: data not shown up after some time Are you sure your app is setting TTL correctly? TTL is in seconds. For 90 days it have to be 90*24*60*60=7776000. What If you set by accident 777600 (10 times less) - that will be 9 days, almost what you see. Best regards / Pagarbiai Viktor Jevdokimov Senior Developer Email: viktor.jevdoki...@adform.com Phone: +370 5 212 3063, Fax +370 5 261 0453 J. Jasinskio 16C, LT-01112 Vilnius, Lithuania Follow us on Twitter: @adforminsider Take a ride with Adform's Rich Media Suite image001.png image002.png Disclaimer: The information contained in this message and attachments is intended solely for the attention and use of the named addressee and may be confidential. If you are not the intended recipient, you are reminded that the information remains the property of the sender. You must not use, disclose, distribute, copy, print or rely on this e-mail. If you have received this message in error, please contact the sender immediately and irrevocably delete this message and any copies. From: Matthias Zeilinger [mailto:matthias.zeilin...@bwinparty.com] Sent: Monday, January 28, 2013 15:57 To: user@cassandra.apache.org Subject: data not shown up after some time Hi, I´m a simple operations guy and new to Cassandra. I have the problem that one of our application is writing data into Cassandra (but not deleting them, because we should have a 90 days TTL). The application operates in 1 KS with 5 CF. my current setup: 3 node cluster and KS has a RF of 3 (I know it´s not the best setup) I can see now the problem that after 10 days most (nearly all) data are not showing anymore in the cli and also our application cannot see the data. I assume that it has something to do with the gc_grace_seconds, it is set to 10 days. I have read many documentations about tombstones, but our application doesn´t perform deletes. How can I see in the cli, if I row key has any tombstone or not. Could it be that there are some ghost tombstones? Thx for your help Br, Matthias Zeilinger Production Operation - Shared Services P: +43 (0) 50 858-31185 M: +43 (0) 664 85-34459 E: matthias.zeilin...@bwinparty.com bwin.party services (Austria) GmbH Marxergasse 1B A-1030
data not shown up after some time
Hi, I´m a simple operations guy and new to Cassandra. I have the problem that one of our application is writing data into Cassandra (but not deleting them, because we should have a 90 days TTL). The application operates in 1 KS with 5 CF. my current setup: 3 node cluster and KS has a RF of 3 (I know it´s not the best setup) I can see now the problem that after 10 days most (nearly all) data are not showing anymore in the cli and also our application cannot see the data. I assume that it has something to do with the gc_grace_seconds, it is set to 10 days. I have read many documentations about tombstones, but our application doesn´t perform deletes. How can I see in the cli, if I row key has any tombstone or not. Could it be that there are some ghost tombstones? Thx for your help Br, Matthias Zeilinger Production Operation - Shared Services P: +43 (0) 50 858-31185 M: +43 (0) 664 85-34459 E: matthias.zeilin...@bwinparty.com bwin.party services (Austria) GmbH Marxergasse 1B A-1030 Vienna www.bwinparty.com
RE: data not shown up after some time
Hi, No I have checked the TTL: 7776000 Very interesting is, if I do a simple list cf; the data is shown, but it I do a get cf where index='testvalue'; it returns 0 Row Returned. How can that be? Br, Matthias Zeilinger Production Operation - Shared Services P: +43 (0) 50 858-31185 M: +43 (0) 664 85-34459 E: matthias.zeilin...@bwinparty.com bwin.party services (Austria) GmbH Marxergasse 1B A-1030 Vienna www.bwinparty.com From: Viktor Jevdokimov [mailto:viktor.jevdoki...@adform.com] Sent: Montag, 28. Jänner 2013 15:25 To: user@cassandra.apache.org Subject: RE: data not shown up after some time Are you sure your app is setting TTL correctly? TTL is in seconds. For 90 days it have to be 90*24*60*60=7776000. What If you set by accident 777600 (10 times less) - that will be 9 days, almost what you see. Best regards / Pagarbiai Viktor Jevdokimov Senior Developer Email: viktor.jevdoki...@adform.commailto:viktor.jevdoki...@adform.com Phone: +370 5 212 3063, Fax +370 5 261 0453 J. Jasinskio 16C, LT-01112 Vilnius, Lithuania Follow us on Twitter: @adforminsiderhttp://twitter.com/#!/adforminsider Take a ride with Adform's Rich Media Suitehttp://vimeo.com/adform/richmedia [Adform News]http://www.adform.com [Adform awarded the Best Employer 2012]http://www.adform.com/site/blog/adform/adform-takes-top-spot-in-best-employer-survey/ Disclaimer: The information contained in this message and attachments is intended solely for the attention and use of the named addressee and may be confidential. If you are not the intended recipient, you are reminded that the information remains the property of the sender. You must not use, disclose, distribute, copy, print or rely on this e-mail. If you have received this message in error, please contact the sender immediately and irrevocably delete this message and any copies. From: Matthias Zeilinger [mailto:matthias.zeilin...@bwinparty.com] Sent: Monday, January 28, 2013 15:57 To: user@cassandra.apache.org Subject: data not shown up after some time Hi, I´m a simple operations guy and new to Cassandra. I have the problem that one of our application is writing data into Cassandra (but not deleting them, because we should have a 90 days TTL). The application operates in 1 KS with 5 CF. my current setup: 3 node cluster and KS has a RF of 3 (I know it´s not the best setup) I can see now the problem that after 10 days most (nearly all) data are not showing anymore in the cli and also our application cannot see the data. I assume that it has something to do with the gc_grace_seconds, it is set to 10 days. I have read many documentations about tombstones, but our application doesn´t perform deletes. How can I see in the cli, if I row key has any tombstone or not. Could it be that there are some ghost tombstones? Thx for your help Br, Matthias Zeilinger Production Operation - Shared Services P: +43 (0) 50 858-31185 M: +43 (0) 664 85-34459 E: matthias.zeilin...@bwinparty.commailto:matthias.zeilin...@bwinparty.com bwin.party services (Austria) GmbH Marxergasse 1B A-1030 Vienna www.bwinparty.comhttp://www.bwinparty.com inline: image001.pnginline: image002.png
RE: data not shown up after some time
How can I check for this secondary index read fails? Is it in the system.log or over the nodetool? Br, Matthias Zeilinger Production Operation - Shared Services P: +43 (0) 50 858-31185 M: +43 (0) 664 85-34459 E: matthias.zeilin...@bwinparty.com bwin.party services (Austria) GmbH Marxergasse 1B A-1030 Vienna www.bwinparty.com From: aaron morton [mailto:aa...@thelastpickle.com] Sent: Dienstag, 29. Jänner 2013 08:04 To: user@cassandra.apache.org Subject: Re: data not shown up after some time If you are seeing failed secondary index reads you may be seeing this https://issues.apache.org/jira/browse/CASSANDRA-5079 Cheers - Aaron Morton Freelance Cassandra Developer New Zealand @aaronmorton http://www.thelastpickle.com On 29/01/2013, at 3:31 AM, Matthias Zeilinger matthias.zeilin...@bwinparty.commailto:matthias.zeilin...@bwinparty.com wrote: Hi, No I have checked the TTL: 7776000 Very interesting is, if I do a simple list cf; the data is shown, but it I do a get cf where index='testvalue'; it returns 0 Row Returned. How can that be? Br, Matthias Zeilinger Production Operation - Shared Services P: +43 (0) 50 858-31185 M: +43 (0) 664 85-34459 E: matthias.zeilin...@bwinparty.commailto:matthias.zeilin...@bwinparty.com bwin.party services (Austria) GmbH Marxergasse 1B A-1030 Vienna www.bwinparty.comhttp://www.bwinparty.com From: Viktor Jevdokimov [mailto:viktor.jevdoki...@adform.comhttp://adform.com] Sent: Montag, 28. Jänner 2013 15:25 To: user@cassandra.apache.orgmailto:user@cassandra.apache.org Subject: RE: data not shown up after some time Are you sure your app is setting TTL correctly? TTL is in seconds. For 90 days it have to be 90*24*60*60=7776000. What If you set by accident 777600 (10 times less) - that will be 9 days, almost what you see. Best regards / Pagarbiai Viktor Jevdokimov Senior Developer Email: viktor.jevdoki...@adform.commailto:viktor.jevdoki...@adform.com Phone: +370 5 212 3063, Fax +370 5 261 0453 J. Jasinskio 16C, LT-01112 Vilnius, Lithuania Follow us on Twitter: @adforminsiderhttp://twitter.com/#!/adforminsider Take a ride with Adform's Rich Media Suitehttp://vimeo.com/adform/richmedia image001.pnghttp://www.adform.com image002.pnghttp://www.adform.com/site/blog/adform/adform-takes-top-spot-in-best-employer-survey/ Disclaimer: The information contained in this message and attachments is intended solely for the attention and use of the named addressee and may be confidential. If you are not the intended recipient, you are reminded that the information remains the property of the sender. You must not use, disclose, distribute, copy, print or rely on this e-mail. If you have received this message in error, please contact the sender immediately and irrevocably delete this message and any copies. From: Matthias Zeilinger [mailto:matthias.zeilin...@bwinparty.comhttp://bwinparty.com] Sent: Monday, January 28, 2013 15:57 To: user@cassandra.apache.orgmailto:user@cassandra.apache.org Subject: data not shown up after some time Hi, I´m a simple operations guy and new to Cassandra. I have the problem that one of our application is writing data into Cassandra (but not deleting them, because we should have a 90 days TTL). The application operates in 1 KS with 5 CF. my current setup: 3 node cluster and KS has a RF of 3 (I know it´s not the best setup) I can see now the problem that after 10 days most (nearly all) data are not showing anymore in the cli and also our application cannot see the data. I assume that it has something to do with the gc_grace_seconds, it is set to 10 days. I have read many documentations about tombstones, but our application doesn´t perform deletes. How can I see in the cli, if I row key has any tombstone or not. Could it be that there are some ghost tombstones? Thx for your help Br, Matthias Zeilinger Production Operation - Shared Services P: +43 (0) 50 858-31185 M: +43 (0) 664 85-34459 E: matthias.zeilin...@bwinparty.commailto:matthias.zeilin...@bwinparty.com bwin.party services (Austria) GmbH Marxergasse 1B A-1030 Vienna www.bwinparty.comhttp://www.bwinparty.com
