[GitHub] [cassandra] aweisberg commented on pull request #2237: CASSANDRA-18129 Accord <-> Paxos live migration

["aweisberg (via GitHub)" <gi...@apache.org>]

aweisberg commented on PR #2237:
URL: https://github.com/apache/cassandra/pull/2237#issuecomment-1503992979

   > I think we need a way to segregate normal and accord data for paxos->accord migration to work correctly. Otherwise the repair and coordinated read operations can replicate data from the future onto the local node.
   
   There is definitely a problem here with coordinators and recovery coordinators. @dcapwell  just fixed [CASSANDRA-18422](https://issues.apache.org/jira/browse/CASSANDRA-18422?filter=-3) which is similar where two coordinators are concurrently reading and writing and one coordinator accidentally reads the writes of the other. The fix there was to invalidate any in-flight reads when committing a write.
   
   The invalidation approach won't help with repair. Seem like for repair the data starts segregated, and we could keep it segregated, and then commit it into Accord in a range transaction?
   
   > The good news is that this would solve the problem of how to run data repairs in clusters where users are mixing normal and accord operations, and if this metadata was the accord execution epoch, it would be pretty useful in bootstrap/range movement/and extended failure recovery.
   Can you elaborate more on this stable component? What would it contain?
   
   
   For coordinated reads. Maybe it makes sense to run those in Accord and route them through their respective command stores so invalidation works? I am not clear if that is better or worse than segregating Accord writes since I don't understand the thinking there yet.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: pr-unsubscribe@cassandra.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: pr-unsubscribe@cassandra.apache.org
For additional commands, e-mail: pr-help@cassandra.apache.org