>
> In case the above doesn't work, another thing to be aware of is that JMX
> uses 2 different ports. The initial connection to 7199 causes a second port
> to be opened, which is normally assigned randomly to an available and
> otherwise unused port above 1024. If your server has a
> firewall/ACL/
Hi Tim,
In case the above doesn't work, another thing to be aware of is that JMX
uses 2 different ports. The initial connection to 7199 causes a second port
to be opened, which is normally assigned randomly to an available and
otherwise unused port above 1024. If your server has a
firewall/ACL/Sec
ok I copied the cassandra.env from the host that had cassandra listening on
port 7199 to the node that wasn't.
That got it listening on the JMX port:
[root@beta:~] #lsof -i :7199
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
java9197 root 45u IPv4 6411278 0t0 TCP *:7199 (L
Try this:
nodetool decomission
UN means UP, NORMAL
--
Colin
+1 320 221 9531
On Sun, May 25, 2014 at 9:09 AM, Tim Dunphy wrote:
> Also for information that may help diagnose this issue I am running
> cassandra 2.0.7
>
> I am also using these java options:
>
> [root@beta:/etc/alternatives/ca
Also for information that may help diagnose this issue I am running
cassandra 2.0.7
I am also using these java options:
[root@beta:/etc/alternatives/cassandrahome] #grep -i jvm_opts
conf/cassandra-env.sh | grep -v '#'
JVM_OPTS="$JVM_OPTS -ea"
JVM_OPTS="$JVM_OPTS -javaagent:$CASSANDRA_HOME/li
Hey all,
I'm attempting to decommission a node I want to remove.
First I get a status of the ring
[root@beta-new:~] #nodetool status
Datacenter: datacenter1
===
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID
>> >> Did you forget to run repair?
>> >>
>> >> On Mon, Jun 21, 2010 at 7:02 PM, Joost Ouwerkerk
>> >> wrote:
>> >> > I believe we did nodetool removetoken on nodes that were already down
>> >> > (due
>> >&
>>
> >> On Mon, Jun 21, 2010 at 7:02 PM, Joost Ouwerkerk
> >> wrote:
> >> > I believe we did nodetool removetoken on nodes that were already down
> >> > (due
> >> > to hardware failure), but I will check to make sure. We're running
> >>
k to make sure. We're running
>> > Cassandra
>> > 0.6.2.
>> >
>> > On Mon, Jun 21, 2010 at 9:59 PM, Joost Ouwerkerk
>> > wrote:
>> >>
>> >> Greg, can you describe the steps we took to decommission the nodes?
>> >>
>> &
gt; > On Mon, Jun 21, 2010 at 9:59 PM, Joost Ouwerkerk
> > wrote:
> >>
> >> Greg, can you describe the steps we took to decommission the nodes?
> >>
> >> -- Forwarded message --
> >> From: Rob Coli
> >> Date: Mon, Jun 21
10 at 9:59 PM, Joost Ouwerkerk
> wrote:
>>
>> Greg, can you describe the steps we took to decommission the nodes?
>>
>> -- Forwarded message --
>> From: Rob Coli
>> Date: Mon, Jun 21, 2010 at 8:08 PM
>> Subject: Re: get_range_slices confus
010 at 8:08 PM
>> Subject: Re: get_range_slices confused about token ranges after
>> decommissioning a node
>> To: user@cassandra.apache.org
>>
>>
>> On 6/21/10 4:57 PM, Joost Ouwerkerk wrote:
>>
>>> We're seeing very strange behaviour after decomm
he nodes?
>
>
> -- Forwarded message --
> From: Rob Coli
> Date: Mon, Jun 21, 2010 at 8:08 PM
> Subject: Re: get_range_slices confused about token ranges after
> decommissioning a node
> To: user@cassandra.apache.org
>
>
> On 6/21/10 4:57 PM, Joost Ouwerk
On 6/21/10 4:57 PM, Joost Ouwerkerk wrote:
We're seeing very strange behaviour after decommissioning a node: when
requesting a get_range_slices with a KeyRange by token, we are getting
back tokens that are out of range.
What sequence of actions did you take to "decommission"
We're seeing very strange behaviour after decommissioning a node: when
requesting a get_range_slices with a KeyRange by token, we are getting back
tokens that are out of range.
As a result, ColumnFamilyRecordReader gets confused, since it uses the last
token from the result set to set the
15 matches
Mail list logo
