First idea to eliminate any issue with regards to staled data: issue the
same count query with RF=QUORUM and check whether there are still
inconsistencies
On Tue, Mar 10, 2015 at 9:13 AM, Rumph, Frens Jan m...@frensjan.nl wrote:
Hi Jens, Mikhail, Daemeon,
Thanks for your replies. Sorry for my
That's it. The clock on one of the nodes was way off. Thanks!!
--
regards,
Gudmundur Johannsson
On Wed, Mar 11, 2015 at 3:42 PM, Roland Etzenhammer
r.etzenham...@t-online.de wrote:
Hi,
I think that your clocks are not in sync. Do you have ntp on all your
nodes up and running with low
Is there a separate forum for Opscenter?
Thanks
Ajay
On 11-Mar-2015 4:16 pm, Ajay ajay.ga...@gmail.com wrote:
Hi,
While adding a Cassandra node using OpsCenter (which is recommended), the
versions of Cassandra (Datastax community edition) shows only 2.0.9 and not
later versions in 2.0.x. Is
It's possible, but you'll end up with problems when attempting to
overwrite or delete entries
I'm wondering if you can elucidate on that a little bit, do you just mean
that it's easy to forget to always set your timestamp correctly, and if you
goof it up, it makes it difficult to recover from
It's always good to run nodetool describecluster after a schema change,
this will show you all the nodes in your cluster and what schema version
they have. If they have different versions you have a schema disagreement
and should follow this guide to resolution:
Hi,
We did our research using 2.0.11 version. While preparing for the
production deployment, found out the following issues:
1) 2.0.12 has nodetool cleanup issue -
https://issues.apache.org/jira/browse/CASSANDRA-8718
2) 2.0.11 has nodetool issue -
There isn't an OpsCenter specific mailing list no.
To answer your question, the reason OpsCenter provisioning doesn't support
2.0.10 and 2.0.11 is due to
https://issues.apache.org/jira/browse/CASSANDRA-8072.
That bug unfortunately prevents OpsCenter provisioning from working
correctly, but isn't
On Thu, Mar 12, 2015 at 10:50 AM, Ajay ajay.ga...@gmail.com wrote:
Please suggest what is the best option in this for production deployment
in EC2 given that we are deploying Cassandra cluster for the 1st time (so
likely that we add more data centers/nodes and schema changes in the
initial
In most datacenters you're going to see significant variance in your server
times. Likely 20ms between servers in the same rack. Even google, using
atomic clocks, has 1-7ms variance. [1]
I would +1 Tyler's advice here, as using the clocks is only valid if clocks
are perfectly sync'ed, which
Correct, Opscenter can monitor 2.0.10 and later clusters/nodes. It just
can't provision them.
On Thu, Mar 12, 2015 at 1:16 PM, Ajay ajay.ga...@gmail.com wrote:
Thanks Nick.
Does it mean that only adding a new node with 2.0.10 or later is a
problem?. If a new node added manually can be
Hi
I had a doubt regarding C* node recovery process.
Assumption : A two data center C* cluster with RF=3 and CL=LOCAL_QUORUM
Suppose a node went down for a period within hinted_handoff time. Once the
node comes up automatic data syncing would start for that node. This
recovery may take some
Thanks Mark.
-
Ajay
On 12-Mar-2015 11:08 pm, Mark Reddy mark.l.re...@gmail.com wrote:
It's always good to run nodetool describecluster after a schema change,
this will show you all the nodes in your cluster and what schema version
they have. If they have different versions you have a schema
Thanks Nick.
Does it mean that only adding a new node with 2.0.10 or later is a
problem?. If a new node added manually can be monitored from Opscenter?
Thanks
Ajay
On 12-Mar-2015 10:19 pm, Nick Bailey n...@datastax.com wrote:
There isn't an OpsCenter specific mailing list no.
To answer your
Seems like its having trouble launching the other EC2 instances that you're
requesting. You would need to provide it your AWS credentials for an
account that has the permissions to create EC2 instances. Have you done
that?
If you just want to install cassandra on AWS, you might find this bash
To clarify on why this behaviour occurs, by default Cassandra will snapshot
a table when you perform any destructive action (TRUNCATE, DROP etc)
see
http://www.datastax.com/documentation/cql/3.0/cql/cql_reference/truncate_r.html
To free disk space after such an operation you will always need to
Ok, but if you're using a system of time that isn't server clock oriented
(Sachin's document revision ID, and my fixed and necessarily consistent
base timestamp [B's always know their parent A's exact recorded
timestamp]), isn't the principle of using timestamps to force a particular
update out of
I'm trying to launch a new instance of DataStax AMI on a EC2 Amazon
instance. I tried this in 2 different regions (us-east and eu-west), using
these AMIs: ami-ada2b6c4, ami-814ec2e8 (us-east) and ami-7f33cd08,
ami-b2212dc6 (eu-west).
I followed this documentation:
Hi Jens, Mikhail, Daemeon,
Thanks for your replies. Sorry for my reply being late ... mails from the
user-list were moved to the wrong inbox on my side.
I'm in a development environment and thus using replication factor = 1 and
consistency = ONE with three nodes. So the 'results from different
18 matches
Mail list logo
