Hi
In our production, we have 3 Cassandra 1.0.11 nodes.
Due to a reason, I want to move the current seed node to another node and
once seed node change, the previous node want to remove from cluster.
How can I do that?
Thanks.
--
View this message in context:
Yes, all this starts because of the call to filter.collateColumns()…
The ColumnFamily is an implementation of o.a.c.dbAbstractColumnContainer , the
methods to add columns on that interface pass through to an implementation of
ISortedColumns.
The implementations of ISortedColumns, e.g.
check 10.50.10.21 for what is the system load.
On Tue, Oct 23, 2012 at 10:41 AM, Jason Hill jasonhill...@gmail.com wrote:
Hello,
I'm on version 1.0.11.
I'm seeing this in my system log with occasional frequency:
INFO [GossipTasks:1] 2012-10-23 02:26:34,449 Gossiper.java (line 818)
and nodetool tpstats always shows pending tasks in the ReadStage.
Are clients reading a single row at a time or multiple rows ? Each row
requested in a multi get becomes a task in the read stage.
Also look at the type of query you are sending. I talked a little about the
performance of
Performing these steps results in the rows still being present using
cassandra-cli list.
I assume you are saying the row key is listed without any columns. aka a ghost
row.
What gets really odd is if I add these steps it works
That's working as designed.
gc_grace_seconds does not
what is the internal memory model used? It sounds like it doesn't have a page
manager?
Nodetool cleanup is a maintenance process to remove data on disk that the node
is no longer a replica for. It is typically used after the token assignments
have been changed.
Cheers
-
Just change the yaml and restart. The seed list is not persisted i the System
KS (like the token assignment).
I would suggest running 2 or 3 seeds in your cluster, even if you only have 3
nodes.
Cheers
-
Aaron Morton
Freelance Developer
@aaronmorton
check 10.50.10.21 for what is the system load.
+1
And take a look in the logs on 10.21.
10.21 is being seen as down by the other nodes. it could be:
* 10.21 failing to gossip fast enough, say by being overloaded to in long
ParNew GC pauses.
* This node failing to process gossip fast , say
Thanks Aaron, my reply is inline below:
On Tue, Oct 23, 2012 at 2:38 AM, aaron morton aa...@thelastpickle.comwrote:
Performing these steps results in the rows still being present using
*cassandra-cli
list*.
I assume you are saying the row key is listed without any columns. aka a
ghost
These GC settings are the default (recommended?) settings from
cassandra-env. I added the UseCompressedOops.
-Bryan
On Mon, Oct 22, 2012 at 6:15 PM, Will @ SOHO w...@voodoolunchbox.comwrote:
On 10/22/2012 09:05 PM, aaron morton wrote:
# GC tuning options
JVM_OPTS=$JVM_OPTS
since SSTABLEs are immutable, it must create new SSTABLEs without the
data that the node is no longer a replica for ... but it doesn't
remove deleted data. seems like a possible optimization to also
removed deleted data and tombstone cleanup ... but i guess cleanup
shouldn't really be used that
Hello,
This conversation precisely targets a question that I had been having for a
while - would be grateful if you someone cloud clarify it a little further:
Considering the case of a repair created due to a consistency constraint
(first case in the discussion above), would the following
In the first example, I am running compaction at step 7 through nodetool,
Sorry missed that.
insert a couple rows with ttl=5 (again, just a small number)
ExpiringColumn's are only purged if their TTL has expired AND their absolute
(node local) expiry time occurred before the current
On Mon, Oct 22, 2012 at 6:05 PM, aaron morton aa...@thelastpickle.comwrote:
The GC was on-going even when the nodes were not compacting or running a
heavy application load -- even when the main app was paused constant the GC
continued.
If you restart a node is the onset of GC activity
Hello,
This conversation precisely targets a question that I had been having for a
while - would be grateful if you someone cloud clarify it a little further:
Considering the case of a repair created due to a consistency constraint
(first case in the discussion above), would the following
thanks for the replies.
I'll check the load on the node that is reported as DOWN/UP. At first
glace it does not appear to be overloaded. But, I will dig in deeper,
is there a specific indicator on an ubuntu server that would be useful
to me?
Also, I didn't make it clear, but in my original post,
why repair again? We block until the consistency constraint is met. Then
the latest version is returned and repair is done asynchronously if any
mismatch. We may retry read if fewer columns than required are returned.
On Wed, Oct 24, 2012 at 6:10 AM, shankarpnsn shankarp...@gmail.com wrote:
manuzhang wrote
why repair again? We block until the consistency constraint is met. Then
the latest version is returned and repair is done asynchronously if any
mismatch. We may retry read if fewer columns than required are returned.
Just to make sure I understand you correct, considering the
I think so. Otherwise, we may never complete a read if writes come in
continuously.
On Wed, Oct 24, 2012 at 9:04 AM, shankarpnsn shankarp...@gmail.com wrote:
manuzhang wrote
why repair again? We block until the consistency constraint is met. Then
the latest version is returned and repair is
Regarding memory usage after a repair ... Are the merkle trees kept around?
On Oct 23, 2012 3:00 PM, Bryan Talbot btal...@aeriagames.com wrote:
On Mon, Oct 22, 2012 at 6:05 PM, aaron morton aa...@thelastpickle.comwrote:
The GC was on-going even when the nodes were not compacting or running a
20 matches
Mail list logo
