Re: Getting error while issuing Cassandra stress

Hi, The the exact command you ran (stress-tool with options) could be useful to help you on that. However, Im able to create keyspace, tables and insert data using cqlsh and > it is replicating fine to all the nodes. Having the schema might be useful too. Did you ran the cqlsh and the

Re: Getting error while issuing Cassandra stress

Sorry I missed that. Both your nodetool status and keyspace replication settings say Cassandra and Analytics for the DC names. I'm not sure where you're seeing DC1, DC2, etc. and why you suspect that is the problem. All the best, [image: datastax_logo.png] Sebastián

Re: Production with Single Node

The risks would be about the same as with a single-node Postgres or MySQL database, except that you wouldn't have the benefit of full SQL. How much data (rows, columns), what kind of load pattern (heavy write, heavy update, heavy query), and what types of queries (primary key-only, slices,

Re: Production with Single Node

I could see this being desirable if you are deploying the exact same application as you deploy in other places with many nodes, and you know the load will be low. It may be a rare situation but in such a case you save big effort by not having to change your application logic. Not that I

Re: Getting error while issuing Cassandra stress

I had a look at the jira below: https://issues.apache.org/jira/browse/CASSANDRA-7905 when i opened my cassandra-rackdc.properties i saw that DC names were DC1 & DC2, rack name was RAC1 . Please note that this is the default configuration, I have not modified any file. There is another point of

Re: Getting error while issuing Cassandra stress

> > when i opened my cassandra-rackdc.properties i saw that DC names were DC1 > & DC2, rack name was RAC1 . Please note that this is the default > configuration, I have not modified any file. cassandra-rackdc.properties is only respected based on your snitch

Production with Single Node

After deploying a number of production systems with up to 10 Cassandra nodes each, we are looking at deploying a small, all-in-one-server system with only a single, local node (Cassandra 2.1.11). What are the risks of such a configuration? The virtual disk would be running RAID 5 and the disk

Fwd: Production with Single Node

Thanks for your reply Jonathan. We chose Cassandra for its incredible performance and robustness for large sites. Our application is designed from the ground up to take full advantage of its column oriented data store (giving up the ability to also run with a relational database backend). The

Re: Production with Single Node

Jeff, that may be true for many ... but for our application, the performance of a single Cassandra node blows the doors off Oracle and PostgreSQL. On Fri, Jan 22, 2016 at 4:24 PM, Jeff Jirsa wrote: > The value of cassandra is in its replication – as a single node

Re: Getting error while issuing Cassandra stress

Yes im specifying -node parameter to stress, otherwise it throws network connection failed. Can you point me to a sample java application to test pushing data from external server? Let's see if that works On Sat, Jan 23, 2016 at 2:55 AM, Sebastian Estevez < sebastian.este...@datastax.com> wrote:

Re: Getting error while issuing Cassandra stress

https://github.com/brianmhess/cassandra-loader All the best, [image: datastax_logo.png] Sebastián Estévez Solutions Architect | 954 905 8615 | sebastian.este...@datastax.com [image: linkedin.png] [image: facebook.png]

Re: Production with Single Node

Thanks for your reply Jonathan. We usually deploy clusters of application nodes running on a Cassandra database cluster, often with two data centers. Our application is married to / designed for Cassandra and we can't support any relational database without rearchitecting and rewriting a lot of

Re: Production with Single Node

Is single-node Cassandra has the performance (and capacity) you need and the NoSQL data model and API are sufficient for your app, and your dev and ops and support teams are already familiar with and committed to Cassandra, and you don't need HA or scaling, then it sounds like you are set. You

Re: Production with Single Node

My opinion: http://rustyrazorblade.com/2013/09/cassandra-faq-can-i-start-with-a-single-node/ TL;DR: the only reason to run 1 node in prod is if you're super broke but know you'll need to scale up almost immediately after going to prod (maybe after getting some funding). If you're planning on

Fwd: Production with Single Node

Thanks for your reply Sebastian. They are specialized data storage & retrieval systems. The Cassandra database is mainly used to store meta-data for searching. Jonathan, I had seen your article. But what are some of the technical reasons why a one node Cassandra cluster is a bad idea? I need

Re: Production with Single Node

The value of cassandra is in its replication – as a single node solution, it’s slower and less flexible than alternatives From: John Lammers Reply-To: "user@cassandra.apache.org" Date: Friday, January 22, 2016 at 12:57 PM To: Cassandra Mailing List Subject: Fwd: Production with Single Node

Re: Getting error while issuing Cassandra stress

The output of `nodetool status` would help us diagnose. All the best, [image: datastax_logo.png] Sebastián Estévez Solutions Architect | 954 905 8615 | sebastian.este...@datastax.com [image: linkedin.png] [image:

Re: Getting error while issuing Cassandra stress

Thanks for the response Alain, cqlsh> create keyspace mykeyspace WITH replication = {'class':'NetworkTopologyStrategy', 'Analytics':2, 'Cassandra':3} cqlsh> use mykeyspace; cqlsh:mykeyspace>create table mytable (id int primary key, name text, address text, phone text); cqlsh:mykeyspace> insert

Re: Using TTL for data purge

On second thought, If you are anyways reading the user table on each website access and can afford extra IO, first option looks more appropriate as it will ease out the pain of manual purging maintenance and wont need full table scans. ThanksAnuj Sent from Yahoo Mail on Android On Sat,

Re: Getting error while issuing Cassandra stress

Hi Sebastian, I had attached nodetool status output in previous mail, pasting it again : $ nodetool status Datacenter: Analytics = Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.41.55.17 428.5 KB 256 ?

Re: Using TTL for data purge

Give a deep thought on your use case. Different user tables/types may have different purge strategy based on how frequently a user account type is usually accessed, whats the user count for each user type and so on. ThanksAnuj Sent from Yahoo Mail on Android On Fri, 22 Jan, 2016 at 11:37

Re: Using TTL for data purge

"As I understand TTL, if there is a compaction of a cell (or row) with a TTL that has been reached, a tombstone will be written.” The expiring cell is treated as a tombstone once it reaches it’s end of life, it does not write an additional tombstone to disk. From:

Re: Using TTL for data purge

Hi Joseph, I am personally in favour of Second approach because I dont want to do lot of IO just because a user is accessing a site several times a day.  Options I see: 1.If you are on SSDs, Test LCS and update TTL of all columns at each access. This will make sure that the system can tolerate

Re: Production with Single Node

Thanks for your response Jack. We are already sold on distributed databases, HA and scaling. We just have some small deployments coming up where there's no money for servers to run multiple Cassandra nodes. So, aside from the lack of HA, I'm asking if a single Cassandra node would be viable in

Re: Production with Single Node

You do of course have the simple technical matters, most of which need to be addressed with a proof of concept implementation, related to memory, storage, latency, and throughput. I mean, with a scaled cluster you can always add nodes to increase capacity and throughput, and reduce latency, but

Re: Production with Single Node

Have you considered running smaller clusters with 1 customer per keyspace? If you're going to run 1 node (and you want to benchmark it properly) then you probably want to switch commitlog_sync to 'batch' and redo your performance tests. Without it, you're risking data loss and you aren't

Re: Getting error while issuing Cassandra stress

Hi Bhuvan, I guess this info will be useful --> https://docs.datastax.com/en/cassandra/2.1/cassandra/tools/toolsCStress_t.html#task_ds_rnm_r53_gk__view-schema-help You could try defining you own settings for the schema (NetworkTopologyStrategy, RF of your choice). Yet SimpleStrategy should work

Re: Production with Single Node

And I think in a 3 node cluster, RAID 0 would do the job instead of RAID 5 . So you will need less storage to get same disk space. But you will get protection against disk failures and infact entire node failure. Anuj Sent from Yahoo Mail on Android On Sat, 23 Jan, 2016 at 10:30 am, Anuj

Re: automated CREATE TABLE just nuked my cluster after a 2.0 -> 2.1 upgrade....

I recall that there was some discussion last year about this issue of how risky it is to do an automated CREATE TABLE IF NOT EXISTS due to the unpredictable amount of time it takes for the table creation to fully propagate around the full cluster. I think it was recognized as a real problem, but

RE: Using TTL for data purge

An upsert is a second insert. Cassandra’s sstables are immutable. There are no real “overwrites” (of the data on disk). It is another record/row. Upon read, it acts like an overwrite, because Cassandra will read both inserts and take the last one in as the correct data. This strategy will work

Re: automated CREATE TABLE just nuked my cluster after a 2.0 -> 2.1 upgrade....

I sort of agree.. but we are also considering migrating to hourly tables.. and what if the single script doesn't run. I like having N nodes make changes like this because in my experience that central / single box will usually fail at the wrong time :-/ On Fri, Jan 22, 2016 at 6:47 PM,

Re: Production with Single Node

I think Jonathan said it earlier. You may be happy with the performance for now as you are using the same commitlog settings that you use in large clusters. Test the new setting recommended so that you know the real picture. Or be prepared to lose some data in case of failure. Other than

Re: Getting error while issuing Cassandra stress

> > Should I use nodetool repair utility > That wouldn't help, this an anti-entropy mechanism (see https://docs.datastax.com/en/cassandra/2.1/cassandra/tools/toolsRepair.html#toolsRepair__description_unique_27 ). It is something really important too often left aside. Yet, your issue here is not

automated CREATE TABLE just nuked my cluster after a 2.0 -> 2.1 upgrade....

Not sure if this is a bug or not or kind of a *fuzzy* area. In 2.0 this worked fine. We have a bunch of automated scripts that go through and create tables... one per day. at midnight UTC our entire CQL went offline.. .took down our whole app. ;-/ The resolution was a full CQL shut down and

Re: automated CREATE TABLE just nuked my cluster after a 2.0 -> 2.1 upgrade....

Instead of using ZK, why not solve your concurrency problem by removing it? By that, I mean simply have 1 process that creates all your tables instead of creating a race condition intentionally? On Fri, Jan 22, 2016 at 6:16 PM Kevin Burton wrote: > Not sure if this is a bug

Re: Getting error while issuing Cassandra stress

Getting same exception again. Should I use nodetool repair utility? On Sat, Jan 23, 2016 at 3:10 AM, Sebastian Estevez < sebastian.este...@datastax.com> wrote: > https://github.com/brianmhess/cassandra-loader > > All the best, > > > [image: datastax_logo.png] > >