Yes, I know it must be in system schema.
But how c* replicates the user defined schema to all nodes? If it
applies the same RWN model to them, then what's the R and W?
And when a failed node comes back to the cluster, how to recover the
schema updates it may miss during the outage?
Any issues if we:
1) create an new empty table with the same structure as the old one
2) create hardlinks ("ln without -s"):
3) run nodetool refresh -- newkeyspacename newtable
and then query/modify both tables independently/simultaneously?
In theory, as SSTables
If you want to copy a portion of the data to another table, you can also
use sstable cql writer. It is more of an advanced feature and can be
tricky, but doable.
once you write the new sstables, you can then use the sstableloader to
stream the new data into the new table.
check this out:
I just need to copy a large table in production without actual copying by using
hardlinks. After this both tables should be used independently (RW). Is this a
supported way or not?
From: Ali Hubail
You should just be able to install 3.1.0 again if you need to as they are
in the 3.X line. To be really safe you can also take a snapshot and backup
your existing SSTables first..and always remember to test before upgrading
in Production :)
On 17 April 2018 at 07:48, Abdul Patel
I am.planning to upgrade my cassandra cluster from 3.1.0 to 3.11.2 . Just
in case if somethings goes back then do we have any rollback or downgrade
option in cassandra to older/ previous version?
> Select * from test where vin =“ZD41578123DSAFWE12313” and create_date in
> (20180416, 20180415, 20180414, 20180413, 20180412….);
> But this cause the cql query is very long,and I don’t know whether there
> is limitation for the length of the cql.
Thanks for the help, I passed the info to our IT.
From: Nate McCall [mailto:n...@thelastpickle.com]
Sent: Monday, April 16, 2018 12:27 AM
To: Cassandra Users
Subject: Re: Mailing list server IPs
I don't think that's true/maybe that comment is misleading. Tombstones
AFAIK will be propagated by hints, and the hint system doesn't do anything
to check if a particular row has been tombstoned. To the node receiving the
hints it just looks like it's receiving a bunch of writes, it doesn't know
Sorry for the delay.
> Is the problem related to token ranges? How can I find out token range for
> each node?
> What can I do to further debug and root cause this?
Very likely. See below.
My previous cluster has 3 nodes but replication factor is 2. I am not
> exactly sure how I would handle
Does c* use predefined keyspace/tables to store the user defined schema?
If so, what's the RWN of those meta schema? And what's the procedure
to update them?
To unsubscribe, e-mail:
There is a system_schema keyspace to store all the schema information
On Mon, Apr 16, 2018 at 10:48 AM, Jinhua Luo wrote:
> Hi All,
> Does c* use predefined
Thanks for the response guys.
Let me try setting token ranges manually and move the data again to correct
nodes. Will update with the outcome soon.
On Tue, Apr 17, 2018 at 5:42 AM, kurt greaves wrote:
> Sorry for the delay.
>> Is the problem related to token ranges?
Mail list logo