Would it help here to not actually issue a delete statement but instead use
date based compaction and a dynamically calculated ttl that is some safe
distance in the future from your key?
Just a thought.
-Thunder
On Mar 25, 2015 11:07 AM, "Robert Coli" wrote:
> On Wed, Mar 25, 2015 at 12:45 AM,
There's no downside to running upgradesstables. I recommend always doing it
on upgrade just to be safe.
On Wed, Mar 25, 2015 at 11:04 AM Jason Wee wrote:
> Sean, thanks and I will keep that in mind for this upgrade. Jason
>
> On Thu, Mar 26, 2015 at 1:23 AM, wrote:
> > Yes, run upgradesstables
Thanks Robert.
Yup, I increased "in_memory_compaction_limit_in_mb" to 512MB so the row in
question fits into it and ran repair on a couple of nodes owning its key.
The log entries about this particular row went away and those columns
haven't reappeared, yet. If that was the reason, that's unfortun
On Wed, Mar 25, 2015 at 1:57 PM, Roman Tkachenko
wrote:
> Okay, so I'm positively going crazy :)
>
> Increasing gc_grace + repair + decreasing gc_grace didn't help. The
> columns still appear after the repair. I checked in cassandra-cli and
> timestamps for these columns are old, not in the futur
Only one, because I ran nodetool compact on the db earlier.
Actually, does nodetool compactionhistory only show the compactions within
the last 24 hours or so? Because I had run nodetool compact about 24 hrs
before i checked compactionhistory, so perhaps the earlier compactions were
just not shown
Okay, so I'm positively going crazy :)
Increasing gc_grace + repair + decreasing gc_grace didn't help. The columns
still appear after the repair. I checked in cassandra-cli and timestamps
for these columns are old, not in the future, so it shouldn't be the reason.
I also did a test: updated one o
How many sstables (*-Data.db files) do each of your two tables have?
On Wed, Mar 25, 2015 at 2:54 PM, Ali Akhtar wrote:
> I also just inserted, didn't do any updates.
>
> On Thu, Mar 26, 2015 at 12:54 AM, Ali Akhtar wrote:
>
>> I'm on 2.0.12
>>
>> I'm not sure if that's issue, since the size is
I'm on 2.0.12
I'm not sure if that's issue, since the size isn't growing. The size is
about what i'd expect.
On Thu, Mar 26, 2015 at 12:44 AM, Tyler Hobbs wrote:
> What version of Cassandra are you using? Since it sounds like you aren't
> doing any reads, it could be
> https://issues.apache.or
I also just inserted, didn't do any updates.
On Thu, Mar 26, 2015 at 12:54 AM, Ali Akhtar wrote:
> I'm on 2.0.12
>
> I'm not sure if that's issue, since the size isn't growing. The size is
> about what i'd expect.
>
> On Thu, Mar 26, 2015 at 12:44 AM, Tyler Hobbs wrote:
>
>> What version of Cas
What version of Cassandra are you using? Since it sounds like you aren't
doing any reads, it could be
https://issues.apache.org/jira/browse/CASSANDRA-8635.
On Wed, Mar 18, 2015 at 9:37 AM, Ali Akhtar wrote:
> When I run nodetool compactionhistory , I'm only seeing the system
> keyspace, and Ops
On Wed, Mar 25, 2015 at 12:45 AM, Robin Verlangen wrote:
> @Robert: can you elaborate a bit more on the "not ideal" parts? In my case
> I will be throwing away the rows (thus the points in time that are "now in
> the past"), which will create tombstones which are compacted away.
>
"Not ideal" is
Sean, thanks and I will keep that in mind for this upgrade. Jason
On Thu, Mar 26, 2015 at 1:23 AM, wrote:
> Yes, run upgradesstables on all nodes - unless you already force major
> compactions on all tables. I run them on a few nodes at a time to minimize
> impact to performance. The upgrade i
Yes, run upgradesstables on all nodes - unless you already force major
compactions on all tables. I run them on a few nodes at a time to minimize
impact to performance. The upgrade is not complete until upgradesstables
completes on all nodes. Then you are safe to resume any streaming operations
hmm... okay.
one more question
https://github.com/apache/cassandra/blob/cassandra-1.1.12/NEWS.txt I
upgraded directly to 1.1.12 , do I need to run nodetool
upgradesstables as stipulated in version 1.1.3 ?
jason
On Wed, Mar 25, 2015 at 1:04 AM, Jonathan Haddad wrote:
> Streaming is repair, addi
Hi there,
@Robert: can you elaborate a bit more on the "not ideal" parts? In my case
I will be throwing away the rows (thus the points in time that are "now in
the past"), which will create tombstones which are compacted away.
@DuyHai: that was exactly what I had in mind and from a C* point of vi
Sorry I misunderstanded your need, you can replace the node with hard drive
failure using
http://www.datastax.com/documentation/cassandra/2.0/cassandra/operations/ops_replace_node_t.html
. In your case the node being replaced has the same ip/host with the "new
node" with new hard drive.
2015-03-25
16 matches
Mail list logo
