Stop writes to a cassandra node for maintenance purpose & enable them after some time

Hi, I want to stop writes to a cassandra node for some time and then start them.Is there any way to do that? Regards

Re: No columns are defined for Materialized View other than primary key

https://issues.apache.org/jira/browse/CASSANDRA-13857 for anyone interested. Appreciate a sanity check on the logic if anyone gets the chance. On 8 September 2017 at 02:14, kurt greaves wrote: > Looks like there are a couple of oversights w.r.t what we allow in the > view

Re: No columns are defined for Materialized View other than primary key

Looks like there are a couple of oversights w.r.t what we allow in the view statement here. I'm creating a JIRA and will link it here shortly as soon as I've fleshed out all the details.​

Re: Cassandra 3.11 is compacting forever

Might be worth turning on debug logging for that node and when the compaction kicks off and CPU skyrockets send through the logs.​

Re: No columns are defined for Materialized View other than primary key

He wants the same primary key, but just wants to filter on site_id = 1 at view creation time. seems like a valid and reasonable use case to me, but I would say this case was overlooked when setting the PK restrictions.

RE: Manual repair not showing in the log.

Yes, I have one validation task in my compactionstats. Thanks Mark 801-705-7115 office From: Carlos Rolo [mailto:r...@pythian.com] Sent: Thursday, September 7, 2017 2:06 PM To: user@cassandra.apache.org Subject: Re: Manual repair not showing in the log. Can you check if you have any validation

Re: Manual repair not showing in the log.

Can you check if you have any validation compaction running in nodetool compactionstats? On 7 Sep 2017 7:56 pm, "Mark Furlong" wrote: I have started a repair and I received the message ‘Starting repair command #1, repairing 25301 ranges for keyspace x

Manual repair not showing in the log.

I have started a repair and I received the message ‘Starting repair command #1, repairing 25301 ranges for keyspace x (parallelism=PARALLEL, full=true). When I look in the log for antientropy repairs I do not see anything for this keyspace. Expecting to see messages for the merkle trees on each

Re: Cassandra compatibility matrix

There aren’t any drivers maintained by the Cassandra project. Compatibility is up to each driver. Usually a section is included in the README. For instance, in the DataStax Java Driver: https://github.com/datastax/java-driver#compatibility

Cassandra compatibility matrix

Hello list! Where can I find C* compatibility matrix for example server server version is compatible with what client drivers? Thank you! - To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org For additional commands,

Re: No columns are defined for Materialized View other than primary key

Clearly, since MV is smaller it can explain, why scanning through it is faster. By full scan I mean issuing series of requests like this SELECT token(site_id,user_id), user_id, data FROM :table WHERE token(site_id, user_id) >= :start AND token(site_id, user_id) <= :stop where (start,stop) pairs

Re: No columns are defined for Materialized View other than primary key

"As I described, non-filtered full scans on MV are more efficient than filtered full scans on a table" --> But if your MV has the same primary key as your view, how can it be possible ? Can you elaborate on what you mean by "non filtered full scan on MV" ? Please give us some sample SELECT

Re: No columns are defined for Materialized View other than primary key

In this example all tables and materialized views share all columns. What is the question? On 7 September 2017 at 17:26, sha p wrote: > There is one more column "data" here in MView? > > On 7 Sep 2017 7:49 p.m., "DuyHai Doan" wrote: > >> The answer

Re: No columns are defined for Materialized View other than primary key

As I described, non-filtered full scans on MV are more efficient than filtered full scans on a table. On 7 September 2017 at 17:19, DuyHai Doan wrote: > The answer of your question is in the error message. For once it's very > clear. The primary key of your materialized

Re: No columns are defined for Materialized View other than primary key

There is one more column "data" here in MView? On 7 Sep 2017 7:49 p.m., "DuyHai Doan" wrote: > The answer of your question is in the error message. For once it's very > clear. The primary key of your materialized view is EXACTLY the same as for > your base table. > > So

Re: No columns are defined for Materialized View other than primary key

The answer of your question is in the error message. For once it's very clear. The primary key of your materialized view is EXACTLY the same as for your base table. So the question is what's the point creating this materialized view ... On Thu, Sep 7, 2017 at 4:01 PM, Alex Kotelnikov <

No columns are defined for Materialized View other than primary key

Hey. I have a problem creating a materialized view. My case is quite similar to https://issues.apache.org/jira/browse/CASSANDRA-13564 but discussion in comments there faded, let me describe by case. I have a table like CREATE TABLE users ( site_id int, user_id text, n int, data

Re: truncate table in C* 3.11.0

Now it's working but nothing changed! In the first attempt (I've tried more that 6 times) that I've reported all the nodes were up, snapshot is disable, and I didn't check the sstables files. All the nodes are up and working hard, another table with 15M inserts/hour and 12k/h queries plus the

Re: truncate table in C* 3.11.0

If you waited less than 60s, no warning/error was issued. Do the following: * Check if all nodes are up (truncate fails if not) * Check if you got a snapshot generated (unless you have auto_snapshot disabled) * Check if you have still the sstables in the directories (you shouldn't) If it didn't

truncate table in C* 3.11.0

Hi list, Using cqlsh: consistency all; select count(*) table1; 219871 truncate table1; select count(*) table1; 219947 There is a consumer reading data from kafka and inserting in C* but the rate is around 50 inserts/minute. Cheers