Originally we would make tables based on keyspace name / table name pairs, which was fine unless you dropped a table and recreated it, which could happen while one node was offline / split network / gc pause. The recreation scenario could allow data to be resurrected after a drop.
So we augmented that (years and years ago) to have a uuid identifier for the table, so now we can differentiate between table creations - if you drop a table and recreate it, the new table has a different id. However, if you issue a create table on two instances at the same time, neither thinks the table exists, each generates their own cfid, two ids get created. Schema eventually gets store inside Cassandra, so last write wins, and the first ID seen gets stomped by the second. The race typically manifests as one instance throwing errors about cfid not found, or a data directory that doesn’t match the cfid in the schema (so a restart creates an empty data directory), or similar situations like that. The actual plumbing to use strong consistency (actually do paxos or some other election to make sure exactly one id wins) is planned, likely for 4.0, but doesn’t exist in any released version now So again, don’t programmatically create tables if there’s a race possible, it may work fine most of the time, but there’s a risk of ugly failure. -- Jeff Jirsa > On Jan 27, 2018, at 1:23 PM, Kant Kodali <k...@peernova.com> wrote: > > May I know why? > > Sent from my iPhone > >> On Jan 27, 2018, at 12:36 PM, Jeff Jirsa <jji...@gmail.com> wrote: >> >> Yes it causes issues >> >> >> -- >> Jeff Jirsa >> >> >>> On Jan 27, 2018, at 12:17 PM, Kant Kodali <k...@peernova.com> wrote: >>> >>> Schema changes I assume you guys are talking about different create table >>> or alter table statements. What if multiple threads issue same exact create >>> table if not exists statement? Will that cause issues? >>> >>> Sent from my iPhone >>> >>>> On Jan 27, 2018, at 11:41 AM, Carlos Rolo <r...@pythian.com> wrote: >>>> >>>> Don't do that. Worst case you might get different schemas in flight and no >>>> agreement on your cluster. If you are already doing that, check "nodetool >>>> describecluster" after you do that. >>>> >>>> Like Jeff said, it is likely to cause problems. >>>> >>>> Regards, >>>> >>>> Carlos Juzarte Rolo >>>> Cassandra Consultant / Datastax Certified Architect / Cassandra MVP >>>> >>>> Pythian - Love your data >>>> >>>> rolo@pythian | Twitter: @cjrolo | Skype: cjr2k3 | Linkedin: >>>> linkedin.com/in/carlosjuzarterolo >>>> Mobile: +351 918 918 100 >>>> www.pythian.com >>>> >>>>> On Sat, Jan 27, 2018 at 7:25 PM, Jeff Jirsa <jji...@gmail.com> wrote: >>>>> It’s not LWT. Don’t do programmatic schema changes that can race, it’s >>>>> likely to cause problems >>>>> >>>>> >>>>> -- >>>>> Jeff Jirsa >>>>> >>>>> >>>>> > On Jan 27, 2018, at 10:19 AM, Kant Kodali <k...@peernova.com> wrote: >>>>> > >>>>> > Hi All, >>>>> > >>>>> > What happens if multiple processes send create table if not exist >>>>> > statement to cassandra? will there be any data corruption or any other >>>>> > issues if I send "create table if not exist" request often? >>>>> > >>>>> > I dont see any entry in system.paxos table so is it fair to say "IF NOT >>>>> > EXISTS" doesn't automatically imply LWT? >>>>> > >>>>> > Thanks! >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org >>>>> For additional commands, e-mail: user-h...@cassandra.apache.org >>>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>>
