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 <http://linkedin.com/in/carlosjuzarterolo>* Mobile: +351 918 918 100 www.pythian.com On Wed, Mar 21, 2018 at 2:04 PM, Rahul Singh <rahul.xavier.si...@gmail.com> 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 <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 > > > -- --
