CASSANDRA-9424 <https://issues.apache.org/jira/browse/CASSANDRA-9424>
All the best, [image: datastax_logo.png] <http://www.datastax.com/> Sebastián Estévez Solutions Architect | 954 905 8615 | sebastian.este...@datastax.com [image: linkedin.png] <https://www.linkedin.com/company/datastax> [image: facebook.png] <https://www.facebook.com/datastax> [image: twitter.png] <https://twitter.com/datastax> [image: g+.png] <https://plus.google.com/+Datastax/about> <http://feeds.feedburner.com/datastax> <http://goog_410786983> <http://www.datastax.com/gartner-magic-quadrant-odbms> DataStax is the fastest, most scalable distributed database technology, delivering Apache Cassandra to the world’s most innovative enterprises. Datastax is built to be agile, always-on, and predictably scalable to any size. With more than 500 customers in 45 countries, DataStax is the database technology and transactional backbone of choice for the worlds most innovative companies such as Netflix, Adobe, Intuit, and eBay. On Sat, Jan 23, 2016 at 12:22 AM, Jack Krupansky <jack.krupan...@gmail.com> wrote: > I recall that there was some discussion last year about this issue of how > risky it is to do an automated CREATE TABLE IF NOT EXISTS due to the > unpredictable amount of time it takes for the table creation to fully > propagate around the full cluster. I think it was recognized as a real > problem, but without an immediate solution, so the recommended practice for > now is to only manually perform the operation (sure, it can be scripted, > but only under manual control) to assure that the operation completes and > that only one attempt is made to create the table. I don't recall if there > was a specific Jira assigned, and the antipattern doc doesn't appear to > reference this scenario. Maybe a committer can shed some more light. > > -- Jack Krupansky > > On Fri, Jan 22, 2016 at 10:29 PM, Kevin Burton <bur...@spinn3r.com> wrote: > >> I sort of agree.. but we are also considering migrating to hourly >> tables.. and what if the single script doesn't run. >> >> I like having N nodes make changes like this because in my experience >> that central / single box will usually fail at the wrong time :-/ >> >> >> >> On Fri, Jan 22, 2016 at 6:47 PM, Jonathan Haddad <j...@jonhaddad.com> >> wrote: >> >>> Instead of using ZK, why not solve your concurrency problem by removing >>> it? By that, I mean simply have 1 process that creates all your tables >>> instead of creating a race condition intentionally? >>> >>> On Fri, Jan 22, 2016 at 6:16 PM Kevin Burton <bur...@spinn3r.com> wrote: >>> >>>> Not sure if this is a bug or not or kind of a *fuzzy* area. >>>> >>>> In 2.0 this worked fine. >>>> >>>> We have a bunch of automated scripts that go through and create >>>> tables... one per day. >>>> >>>> at midnight UTC our entire CQL went offline.. .took down our whole app. >>>> ;-/ >>>> >>>> The resolution was a full CQL shut down and then a drop table to remove >>>> the bad tables... >>>> >>>> pretty sure the issue was with schema disagreement. >>>> >>>> All our CREATE TABLE use IF NOT EXISTS.... but I think the IF NOT >>>> EXISTS only checks locally? >>>> >>>> My work around is going to be to use zookeeper to create a mutex lock >>>> during this operation. >>>> >>>> Any other things I should avoid? >>>> >>>> >>>> -- >>>> >>>> We’re hiring if you know of any awesome Java Devops or Linux Operations >>>> Engineers! >>>> >>>> Founder/CEO Spinn3r.com >>>> Location: *San Francisco, CA* >>>> blog: http://burtonator.wordpress.com >>>> … or check out my Google+ profile >>>> <https://plus.google.com/102718274791889610666/posts> >>>> >>>> >> >> >> -- >> >> We’re hiring if you know of any awesome Java Devops or Linux Operations >> Engineers! >> >> Founder/CEO Spinn3r.com >> Location: *San Francisco, CA* >> blog: http://burtonator.wordpress.com >> … or check out my Google+ profile >> <https://plus.google.com/102718274791889610666/posts> >> >> >
