Re: Is this SSTable restore merging scenario possible ?

[Carlos Rolo]

As said before, as long as you rename the UUIDs to match you should be good.

The Production "win out" depends on the timestamps. In Cassandra last write
wins, so as long as, for the same row, the production timestamps are more
recent than the secondary cluster, the production data would "win over".

Regards,

Carlos Juzarte Rolo
Cassandra Consultant / Datastax Certified Architect / Cassandra MVP

Pythian - Love your data

rolo@pythian | Twitter: @cjrolo | Skype: cjr2k3 | Linkedin:
*linkedin.com/in/carlosjuzarterolo
*
Mobile: +351 918 918 100
www.pythian.com

On Wed, Mar 21, 2018 at 2:04 PM, Rahul Singh 
wrote:

> If its not on the same “cluster” and you are not using something like
> OpsCenter, the snapshotted files will have a diferent schema UUID for each
> entity. If you rename the files to have the matching UUID in the file
> names, then you should be able to do what you are talking about.
>
> On Mar 21, 2018, 4:50 AM -0500, Andrew Voumard ,
> wrote:
>
> Hi All,
>
> I am using Cassandra 3.10
>
> I would like to know if the following SSTable row level merging scenario
> is possible:
>
> 1. On a Production Cluster
> - Take a full snapshot on every node
>
> 2. On a new, empty Secondary Cluster with the same topology
> - Create a matching schema (keyspaces + tables as the production cluster).
> Note: The schema is very simple: No secondary or SASI indices, materialized
> views, etc.
> - Restore the full snapshots from production on each corresponding
> secondary node
> - INSERT rows into tables on the secondary node, but with keys that are
> guaranteed to be different to any INSERTs that were restored from the
> production cluster
> - UPDATE some of the existing rows in the secondary cluster (these are
> rows originally from the production cluster)
>
> 3. On the Production Cluster
> - Apply INSERTs, UPDATEs and DELETEs to tables
> - Take an incremental snapshot on every node
>
> 4. On the Secondary Cluster
> - Attempt to restore the incremental snapshots from the Production Cluster
> on each corresponding secondary cluster node, using nodetool refresh
>
> Question: Will Step 4 be successful ?, reiterating that:
> - The INSERTs will not have conflicting keys (as noted above)
> - The Production Cluster may have made UPDATES to rows that the Secondary
> Cluster has also made UPDATEs to
> - The Production Cluster may have DELETEd rows which the Secondary Cluster
> has UPDATED in the meantime
>
> If it works, I would expect the changes from Production to "win out" over
> any made independently on the Secondary Cluster.
>
> Many Thanks for any help you can provide
>
>
>

-- 


--

Re: Is this SSTable restore merging scenario possible ?

[Rahul Singh]

If its not on the same “cluster” and you are not using something like 
OpsCenter, the snapshotted files will have a diferent schema UUID for each 
entity. If you rename the files to have the matching UUID in the file names, 
then you should be able to do what you are talking about.

On Mar 21, 2018, 4:50 AM -0500, Andrew Voumard , wrote:
> Hi All,
>
> I am using Cassandra 3.10
>
> I would like to know if the following SSTable row level merging scenario is 
> possible:
>
> 1. On a Production Cluster
> - Take a full snapshot on every node
>
> 2. On a new, empty Secondary Cluster with the same topology
> - Create a matching schema (keyspaces + tables as the production cluster). 
> Note: The schema is very simple: No secondary or SASI indices, materialized 
> views, etc.
> - Restore the full snapshots from production on each corresponding secondary 
> node
> - INSERT rows into tables on the secondary node, but with keys that are 
> guaranteed to be different to any INSERTs that were restored from the 
> production cluster
> - UPDATE some of the existing rows in the secondary cluster (these are rows 
> originally from the production cluster)
>
> 3. On the Production Cluster
> - Apply INSERTs, UPDATEs and DELETEs to tables
> - Take an incremental snapshot on every node
>
> 4. On the Secondary Cluster
> - Attempt to restore the incremental snapshots from the Production Cluster on 
> each corresponding secondary cluster node, using nodetool refresh
>
> Question: Will Step 4 be successful ?, reiterating that:
> - The INSERTs will not have conflicting keys (as noted above)
> - The Production Cluster may have made UPDATES to rows that the Secondary 
> Cluster has also made UPDATEs to
> - The Production Cluster may have DELETEd rows which the Secondary Cluster 
> has UPDATED in the meantime
>
> If it works, I would expect the changes from Production to "win out" over any 
> made independently on the Secondary Cluster.
>
> Many Thanks for any help you can provide
>
>

Is this SSTable restore merging scenario possible ?

[Andrew Voumard]

Hi All,

I am using Cassandra 3.10

I would like to know if the following SSTable row level merging scenario is 
possible:

1. On a Production Cluster
- Take a full snapshot on every node

2. On a new, empty Secondary Cluster with the same topology
- Create a matching schema (keyspaces + tables as the production cluster). 
Note: The schema is very simple: No secondary or SASI indices, materialized 
views, etc.
- Restore the full snapshots from production on each corresponding secondary 
node
- INSERT rows into tables on the secondary node, but with keys that are 
guaranteed to be different to any INSERTs that were restored from the 
production cluster
- UPDATE some of the existing rows in the secondary cluster (these are rows 
originally from the production cluster)

3. On the Production Cluster
- Apply INSERTs, UPDATEs and DELETEs to tables
- Take an incremental snapshot on every node

4. On the Secondary Cluster
- Attempt to restore the incremental snapshots from the Production Cluster on 
each corresponding secondary cluster node, using nodetool refresh

Question: Will Step 4 be successful ?, reiterating that:
- The INSERTs will not have conflicting keys (as noted above)
- The Production Cluster may have made UPDATES to rows that the Secondary 
Cluster has also made UPDATEs to
- The Production Cluster may have DELETEd rows which the Secondary Cluster has 
UPDATED in the meantime

If it works, I would expect the changes from Production to "win out" over any 
made independently on the Secondary Cluster.

Many Thanks for any help you can provide