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 no
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 wrote:
> Hi Jens, Mikhail, Daemeon,
>
> Thanks for your replies. Sorry for my reply being l
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
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:
http://www.datastax.com/documenta
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
scri
> 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 (i
Is there a separate forum for Opscenter?
Thanks
Ajay
On 11-Mar-2015 4:16 pm, "Ajay" 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 there a reaso
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
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:
http://www.datastax.com/documentat
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 -
https://issues.apache.org/jira/browse/CASSANDRA-8
Thanks Mark.
-
Ajay
On 12-Mar-2015 11:08 pm, "Mark Reddy" 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 disagreement
> an
On Thu, Mar 12, 2015 at 10:50 AM, Ajay 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 few months)
>
Voti
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" wrote:
> There isn't an OpsCenter specific mailing list no.
>
> To answer your question, the
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 t
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 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 monitored from Opscente
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 tim
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
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 c
When I try to launch an EC2 Instance using DataStax community it's working,
so I have the premission to create an EC2 instance. I want to have
Cassandra and Solr as services installed on an VM.
Thanks!
On Thu, Mar 12, 2015 at 2:56 PM, Ali Akhtar wrote:
> Seems like its having trouble launching
19 matches
Mail list logo
