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>
