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 <andr...@melbpc.org.au>, 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 > >
