Hi Jeff, Thank you for your reply! Yes, we are working on generating a deterministic CFID at table creation time. We will also most likely block the pattern of drop and create to avoid the data reassurance issue once we identify all the potential risks with the deterministic id. That's why I asked to create some dtests to reproduce the schema disagreement issue and show the deterministic table id can avoid the issue.
Thanks Cheng On Mon, Aug 8, 2022 at 4:46 PM Jeff Jirsa <jji...@gmail.com> wrote: > I see. Then yes, make a cluster with at least 2 hosts, run the CREATE > TABLE on them at the same time. If you use the pause injection framework, > you can probably pause threads after the CFID is generated but before it's > broadcast. > > If you make the CFID deterministic, you can avoid the race, but can run > into problems if you create/drop/create (a node that was down during the > drop may resurrect data) > > If you leave the CFID non-deterministic, the only way you're going to get > safety is a global ordering or transactional system, which more or less > reduces down to https://issues.apache.org/jira/browse/CASSANDRA-10699 > > Now, there are some things you can do to minimize risk along the way - you > could try to hunt down all of the possible races where in-memory state and > on-disk state diverge, create signals/log messages / warnings to make it > easier to detect, etc. But I'd be worried that any partial fixes will > complicate 10699 (either make the merge worse, or be outright removed > later), so it may be worth floating your proposed fix before you invest a > ton of time on it. > > > > > > > > > On Mon, Aug 8, 2022 at 3:57 PM Cheng Wang <che...@netflix.com> wrote: > >> Jeff, >> >> The issue I was trying to address is when there are two CREATE TABLE >> queries running on two coordinator nodes concurrently, it might end up with >> 2 schema versions and they would never get resolved automatically because >> table id is random TimeUUID. >> >> >> >> On Mon, Aug 8, 2022 at 3:54 PM Jeff Jirsa <jji...@gmail.com> wrote: >> >>> Which (of the many) schema disagreement issue(s)? >>> >>> >>> >>> On Mon, Aug 8, 2022 at 3:29 PM Cheng Wang via dev < >>> dev@cassandra.apache.org> wrote: >>> >>>> Thank you for the reply, Brandon! It is helpful! >>>> >>>> I was thinking of creating a cluster with 2 nodes and having two >>>> concurrent CREATE TABLE statements running. But the test will be flaky as >>>> there is no guarantee that the query runs before the schema agreement has >>>> been reached. >>>> Any ideas for that? >>>> >>>> Thanks, >>>> Cheng >>>> >>>> On Mon, Aug 8, 2022 at 3:19 PM Brandon Williams <dri...@gmail.com> >>>> wrote: >>>> >>>>> If you simply do a lot of schema changes quickly without waiting for >>>>> agreement, that should get you there. >>>>> >>>>> Kind Regards, >>>>> Brandon >>>>> >>>>> On Mon, Aug 8, 2022 at 5:08 PM Cheng Wang via dev >>>>> <dev@cassandra.apache.org> wrote: >>>>> > >>>>> > Hello, >>>>> > >>>>> > I am working on improving the schema disagreement issue. I need some >>>>> dtests which can reproduce the schema disagreement. Anyone know if there >>>>> are any existing tests for that? Or something similar? >>>>> > >>>>> > Thanks >>>>> > Cheng >>>>> >>>>
