Hi David,
I'm not running Cassandra 2.0.2, but I'm used to move the data from a
Cassandra cluster with vnodes to another one.
I will do the same for backuping the cluster A.
In order to restore cluster B, I do the following steps:
1. Deploy 5 nodes as part of the cluster-B ring.
2. Create keys
> we then take the snapshot archive generated FROM cluster-A_node1 and
> copy/extract/restore TO cluster-B_node1, then we
sounds correct.
> Depending on what additional comments/recommendation you or another member of
> the list may have (if any) based on the clarification I've made above,
Al
Thank you for the detailed reply Rob! I have replied to your comments in-line
below;
On Nov 14, 2013, at 1:15 PM, Robert Coli wrote:
> On Thu, Nov 14, 2013 at 12:37 PM, David Laube wrote:
> It is almost as if the data only exists on some of the nodes, or perhaps the
> token ranges are dramat
On Thu, Nov 14, 2013 at 12:37 PM, David Laube wrote:
> It is almost as if the data only exists on some of the nodes, or perhaps
> the token ranges are dramatically different --again, we are using vnodes so
> I am not exactly sure how this plays into the equation.
The token ranges are dramatical
Hi All,
After running through our backup and restore process FROM our test production
TO our staging environment, we are seeing inconsistent reads from the cluster
we restored to. We have the same number of nodes in both clusters. For example,
we will select data from a column family on the new
