I created an issue for this:
https://issues.apache.org/jira/browse/CASSANDRA-8801
On Thu, Feb 12, 2015 at 10:18 AM, Robert Coli wrote:
> On Thu, Feb 12, 2015 at 7:04 AM, Eric Stevens wrote:
>
>> IMO, especially with the threat to unrecoverable consistency violations,
>> this should be a critica
On Thu, Feb 12, 2015 at 7:04 AM, Eric Stevens wrote:
> IMO, especially with the threat to unrecoverable consistency violations,
> this should be a critical bug.
>
You should file a JIRA, and let the list know what it is? :D
I was never sure if it was just me being unreasonably literal to presum
Definitely, I think the very same re this issue.
On Thu, Feb 12, 2015 at 7:04 AM, Eric Stevens wrote:
> I definitely find it surprising that a node which was decommissioned is
> willing to rejoin a cluster. I can't think of any legitimate scenario
> where you'd want that, and I'm surprised the
I definitely find it surprising that a node which was decommissioned is
willing to rejoin a cluster. I can't think of any legitimate scenario
where you'd want that, and I'm surprised the node doesn't track that it was
decommissioned and refuse to rejoin without at least a -D flag to force it.
Way
And after decreasing your RF (rare but happens)
On Wed Feb 11 2015 at 11:31:38 AM Robert Coli wrote:
> On Wed, Feb 11, 2015 at 11:20 AM, Jonathan Haddad
> wrote:
>
>> It could, because the tombstones that mark data deleted may have been
>> removed. There would be nothing that says "this data i
On Wed, Feb 11, 2015 at 11:20 AM, Jonathan Haddad wrote:
> It could, because the tombstones that mark data deleted may have been
> removed. There would be nothing that says "this data is gone".
>
> If you're worried about it, turn up your gc grace seconds. Also, don't
> revive nodes back into a
> On Tue, Feb 10, 2015 at 9:13 PM, Stefano Ortolani
>> wrote:
>>
>>> I recommissioned a node after decommissioningit.
>>> That happened (1) after a successfull decommission (checked), (2)
>>> without wiping the data directory on the node, (3) simply by restartin
restart after the gc_grace_seconds passed
would have violated consistency permanently?
Cheers,
Stefano
On Wed, Feb 11, 2015 at 10:56 AM, Robert Coli wrote:
> On Tue, Feb 10, 2015 at 9:13 PM, Stefano Ortolani
> wrote:
>
>> I recommissioned a node after decommissioningit.
>
On Tue, Feb 10, 2015 at 9:13 PM, Stefano Ortolani
wrote:
> I recommissioned a node after decommissioningit.
> That happened (1) after a successfull decommission (checked), (2) without
> wiping the data directory on the node, (3) simply by restarting the
> cassandra service. The node
uests without having a consistent view of the data.
>> A safer approach would be to wipe the data directory and bootstrap it as a
>> clean new member.
>>
>> I'm curious what prompted that cycle of decommission then recommission.
>>
>> On Tue, Feb 10, 2015
o Ortolani
> wrote:
>
>> Hi,
>>
>> I recommissioned a node after decommissioningit.
>> That happened (1) after a successfull decommission (checked), (2) without
>> wiping the data directory on the node, (3) simply by restarting the
>> cassandra service.
n new member.
I'm curious what prompted that cycle of decommission then recommission.
On Tue, Feb 10, 2015 at 10:13 PM, Stefano Ortolani
wrote:
> Hi,
>
> I recommissioned a node after decommissioningit.
> That happened (1) after a successfull decommission (checked), (2) wit
Hi,
I recommissioned a node after decommissioningit.
That happened (1) after a successfull decommission (checked), (2) without
wiping the data directory on the node, (3) simply by restarting the
cassandra service. The node now reports himself healty and up and running
Knowing that I issued the
13 matches
Mail list logo
