On Tue, Nov 25, 2014 at 6:40 AM, Ankit Patel wrote:
> The JIRA https://issues.apache.org/jira/browse/CASSANDRA-4446 refers to
> the problem after we've invoked drain. However, we did not invoke drain or
> flush. We are running one node cassandra within one data center and it is
> being replicated
Rob,
The JIRA https://issues.apache.org/jira/browse/CASSANDRA-4446 refers to the
problem after we've invoked drain. However, we did not invoke drain or
flush. We are running one node cassandra within one data center and it is
being replicated with another node in another data center. We are using
On Mon, Nov 24, 2014 at 5:51 PM, Robert Coli wrote:
> What is your replication factor? What CL are you using to read?
>
Ah, I see from OP that RF is 1.
As a general statement, RF=1 is an edge case which very, very few people
have ever operated in production. It is relatively likely that there a
On Mon, Nov 24, 2014 at 3:19 PM, Ankit Patel wrote:
> We are experiencing data loss with Cassandra 1.0.10 when we had restarted
> the without flushing. We see in the cassandra logs that the commitlogs were
> read back without any problems. Until the restart the data was correct.
> However, after
We are experiencing data loss with Cassandra 1.0.10 when we had restarted
the without flushing. We see in the cassandra logs that the commitlogs were
read back without any problems. Until the restart the data was correct.
However, after the node restarted we retrieved older version of the data
(row
