cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-1391) Allow Concurrent Schema Migrations
Date Sat, 30 Jul 2011 04:12:09 GMT


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:
>             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:


View raw message