Re: Concurrent schema creation/change strategy

[Jens Rantil]

Hi,

Generally it can take a couple of seconds before a schema change has
propagated to all nodes. The schema will in most cases converge, but as far
as I've understood, concurrent schema changes are considered a bad practise
and can lead to inconsistent schemas down the road. IIRC if one executes
all schema changes from the same node one can be certain that the schema
changes will converge. After executing a schema change you can execute
`nodetool describecluster` to make sure all nodes have the same schema.

What I'd suggest is that you either

   - introduce a queue to execute the schema changes from a single node; or
   - come up with the schema that works generically over time; or
   - somehow introduce a global lock if you are to programatically alter
   schema. Lock, make change, poll until all nodes have the same schema,
   release lock.

Those are mu 5 cents. There are probably other solutions.

Cheers,
Jens

On Mon, May 25, 2015 at 10:58 AM, Magnus Vojbacke 
magnus.vojba...@digitalroute.com wrote:

 I have a lot of clients that will try to create the same schema (a
 keyspace with multiple tables) concurrently during application startup. The
 idea is that the first time the application starts, the clients will create
 the schema needed to run (create if not exists, etc...)

 From what I’ve read, I think that Cassandra has support for concurrent
 schema creation and modification, but I assume there will be conflicts of
 some sort.


 Is there any known strategy for handling this? Specifically considering
 conflicts.

 In case of a conflict (e.g., two clients trying to create the exact same
 table), will the client call return with an error? (Datastax driver)

 Would a plausible strategy be (for each client) 1) try to create the
 table, 2) examine any error coming back to determine if a conflict
 happened, 3) if conflict, move on to next table?

 Or is it just better to add a separate step to create the schema at some
 point in time before the clients can be allowed to work (i.e. move schema
 creation out of the clients)?




 Thanks
 /Magnus




-- 
Jens Rantil
Backend engineer
Tink AB

Email: jens.ran...@tink.se
Phone: +46 708 84 18 32
Web: www.tink.se

Facebook https://www.facebook.com/#!/tink.se Linkedin
http://www.linkedin.com/company/2735919?trk=vsrp_companies_res_phototrkInfo=VSRPsearchId%3A1057023381369207406670%2CVSRPtargetId%3A2735919%2CVSRPcmpt%3Aprimary
 Twitter https://twitter.com/tink

Concurrent schema creation/change strategy

[Magnus Vojbacke]

I have a lot of clients that will try to create the same schema (a keyspace 
with multiple tables) concurrently during application startup. The idea is that 
the first time the application starts, the clients will create the schema 
needed to run (create if not exists, etc...)

From what I’ve read, I think that Cassandra has support for concurrent schema 
creation and modification, but I assume there will be conflicts of some sort.


Is there any known strategy for handling this? Specifically considering 
conflicts.

In case of a conflict (e.g., two clients trying to create the exact same 
table), will the client call return with an error? (Datastax driver)

Would a plausible strategy be (for each client) 1) try to create the table, 2) 
examine any error coming back to determine if a conflict happened, 3) if 
conflict, move on to next table?

Or is it just better to add a separate step to create the schema at some point 
in time before the clients can be allowed to work (i.e. move schema creation 
out of the clients)?




Thanks
/Magnus