On altering the Keyspace, the warning disappears. I think the warning was not
totally wrong, just slightly inaccurate.
From: Nitan Kainth [mailto:nitankai...@gmail.com]
Sent: Wednesday, June 13, 2018 4:38 PM
To: user@cassandra.apache.org
Subject: Re: Restoring snapshot
Change RF fir k2 and
ica could be found” but the question is, why is it giving
> the name of keyspace K2 when I was restoring only K1(It should have given
> warning for K1).
>
> From: Nitan Kainth [mailto:nitankai...@gmail.com]
> Sent: Wednesday, June 13, 2018 4:31 PM
> To: user@cassandra.apache.o
have given warning
for K1).
From: Nitan Kainth [mailto:nitankai...@gmail.com]
Sent: Wednesday, June 13, 2018 4:31 PM
To: user@cassandra.apache.org
Subject: Re: Restoring snapshot
Verify dc name and replication factor in create keyspace command in new cluster.
Sent from my iPhone
On Jun 13, 2018, at
Verify dc name and replication factor in create keyspace command in new cluster.
Sent from my iPhone
> On Jun 13, 2018, at 2:40 AM,
> wrote:
>
> Dear Community,
>
> I took a snapshot from a node which was part of a 2 node cluster. There were
> 2 keyspaces in that cluster K1 and K2. I took
Dear Community,
I took a snapshot from a node which was part of a 2 node cluster. There were 2
keyspaces in that cluster K1 and K2. I took snapshot of K1 only. Now I create
both keyspaces in some other cluster having only one node. When I tried to
restore the snapshot(of keyspace K1) in that cl
Before restoring check version od sstables which you are using to import
data into your schema. , as you remove and add age, due to this, already
there will be no data for that column.
now if you want that your old data should be shown here, then you have to
use proper sstable for dumping the data
Hi Vishal!
Did you copy the sstables into data directory?
another thing is, check the id of the table that is the same as casaandra
has in the metadata with the directory.
https://docs.datastax.com/en/dse/5.1/cql/cql/cql_using/useCreateTableCollisionFix.html
El El lun, 11 de jun. de 2018 a
It's possible that it's something more subtle, but keep in mind that
sstables don't include the schema. If you've made schema changes, you need
to apply/revert those first or C* probably doesn't know what to do with
those columns in the sstable.
On Sun, Jun 10, 2018 at 11:38 PM, wrote:
> Dear C
Dear Community,
I’ll appreciate if I can get some responses to the observation below:
https://stackoverflow.com/q/50763067/5701173
Thanks and regards,
Vishal Sharma
"Confidentiality Warning: This message and any attachments are intended only
for the use of the intended recipient(s).
are confid
hra wrote:
> Sean,
>
> I meant commit log archival was never part of "restoring snapshot"
> DataStax documentation. How commitlog archival is related to my concern?
> Please elaborate.
>
> Thanks
> Anuj
>
> Sent from Yahoo Mail on Android
> <https://overv
Sean,
I meant commit log archival was never part of "restoring snapshot" DataStax
documentation. How commitlog archival is related to my concern? Please
elaborate.
ThanksAnuj
Sent from Yahoo Mail on Android
On Thu, 28 Apr, 2016 at 9:24 PM,
sean_r_dur...@homedepot.com wrote
https://docs.datastax.com/en/cassandra/2.0/cassandra/configuration/configLogArchive_t.html
Sean Durity
From: Anuj Wadehra [mailto:anujw_2...@yahoo.co.in]
Sent: Wednesday, April 27, 2016 10:44 PM
To: user@cassandra.apache.org
Subject: RE: Inconsistent Reads after Restoring Snapshot
No.We are not
?
Sean Durity
From: Anuj Wadehra [mailto:anujw_2...@yahoo.co.in]
Sent: Monday, April 25, 2016 10:26 PM
To: User
Subject: Inconsistent Reads after Restoring Snapshot
Hi,
We have 2.0.14. We use RF=3 and read/write at Quorum. Moreover, we dont use
incremental backups
What about the commitlogs? Are you saving those off anywhere in between the
snapshot and the crash?
Sean Durity
From: Anuj Wadehra [mailto:anujw_2...@yahoo.co.in]
Sent: Monday, April 25, 2016 10:26 PM
To: User
Subject: Inconsistent Reads after Restoring Snapshot
Hi,
We have 2.0.14. We use RF
tion during autobootstrap :)
Thanks
Anuj
On Tue, 26/4/16, Romain Hardouin wrote:
Subject: Re: Inconsistent Reads after Restoring Snapshot
To: "user@cassandra.apache.org"
Date: Tuesday, 26 April, 2016, 12:47 PM
You can make a restore on t
Romain Hardouin wrote:
Subject: Re: Inconsistent Reads after Restoring Snapshot
To: "user@cassandra.apache.org"
Date: Tuesday, 26 April, 2016, 12:47 PM
You can make a restore on the new node A (don't
forget to set the token(s) in cassandra.yaml), start the
node with -Dcassandr
You can make a restore on the new node A (don't forget to set the token(s) in
cassandra.yaml), start the node with -Dcassandra.join_ring=false and then run a
repair on it. Have a look at
https://issues.apache.org/jira/browse/CASSANDRA-6961
Best,
Romain
Le Mardi 26 avril 2016 4h26, Anuj Wad
Hi,
We have 2.0.14. We use RF=3 and read/write at Quorum. Moreover, we dont use
incremental backups. As per the documentation at
https://docs.datastax.com/en/cassandra/2.0/cassandra/operations/ops_backup_snapshot_restore_t.html
, if i need to restore a Snapshot on SINGLE node in a cluster, I wou
Hello,
That's a large variation between the old and new cluster. Are you sure
you pulled over all the SSTables for your keyspaces? Also, did you run a
repair after the data move? Do you have a lot of tombstone data in the old
cluster that was removed during the migration process? Are you usi
Hi
I have two separated clusters consist of 4 nodes. One cluster is running on
1.2.12 and the other one on 2.0.5. I loaded data from first cluster
(1.2.12) to the second one (2.0.5) by copying snapshots between
corresponding nodes. I removed commitlogs, started second cluster and run
nodetool upgr
20 matches
Mail list logo
