[ 
https://issues.apache.org/jira/browse/CASSANDRA-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073124#comment-13073124
 ] 

Jonathan Ellis commented on CASSANDRA-1391:
-------------------------------------------

Thinking about this more, the really important part is that all nodes agree on 
the same schema no matter what order they get the Migrations in.  If we can 
make that guarantee, the actual conflict resolution doesn't have to be 
particularly good (since it will still be a rare occurrence).

So what is "the simplest thing that can work" here?

I think we need to be able to merge Migrations at a finer granularity.

If we do not, we have problems like this:

- Mutation 1 (M1) says "set default_validation_class=ascii, comment='foo'" at 
time T1.
- M2 says "set row_cache_size=1000000" at time T0 < T1.

If node A gets M2 first, applies it, then gets M1, it has all 3 changes made.  
If node B however gets M1 first, then rejects M2 because T0 < T1 (for whatever 
kind of clock/comparator we are talking about), nodes A and B will end up with 
different schemas.

I think wall-clock-time plus content-based tiebreaker (like we currently do 
with Column values) will be just as good as more complex ordering, as long as 
we have the fine-grained merging.

> Allow Concurrent Schema Migrations
> ----------------------------------
>
>                 Key: CASSANDRA-1391
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1391
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Stu Hood
>            Assignee: Gary Dusbabek
>
> CASSANDRA-1292 fixed multiple migrations started from the same node to 
> properly queue themselves, but it is still possible for migrations initiated 
> on different nodes to conflict and leave the cluster in a bad state. Since 
> the system_add/drop/rename methods are accessible directly from the client 
> API, they should be completely safe for concurrent use.
> It should be possible to allow for most types of concurrent migrations by 
> converting the UUID schema ID into a VersionVectorClock (as provided by 
> CASSANDRA-580).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to