+1 for Jon K's comment!
On Sun, May 9, 2021 at 9:14 PM Jonathan Koppenhofer
wrote:
> I addition to Jeff's answer... Certificate hot reloading... For an
> organization that uses annual certs :)
>
>
> On Fri, May 7, 2021, 8:47 AM Durity, Sean R
> wrote:
>
>> There is not enough 4.0 chatter here.
Having said that, I'm still not a fan of making schema changes
programmatically. I spend way too much time helping users unscramble their
schema after they've hit multiple disagreements. I do understand the need
for it but avoid it if you can particularly in production.
On Fri, 4 Jun 2021 at
>
> I wonder if there’s a way to query the driver to see if your schema change
> has fully propagated. I haven’t looked into this.
>
Yes, the drivers have APIs for this. For example, the Java driver has
isSchemaInAgreement() and checkSchemaAgreement().
See
Hi Joe,
In our case we only do this in the test environment and it could be the case
that there are several seconds or even minutes between when a schema change
occurs vs when a test executes that depends on said schema change. Perhaps we
have been lucky thus far. :-)
I wonder if there’s a
CFID mismatch is not "schema not propagated", it means you created the
table twice at the same time, and you have an inconsistent view of the
table within your cluster.
This is bad. Really bad. Worse than you expect. It's a bug in cassandra,
but until it's fixed, you should stop doing concurrent
Sometimes even waiting hours does not change. I have a cluster where I did
like you, synchronization of create tables statement, then even I tried
waiting for schema agreement, in loop until success, but sometimes the
success never happens, i got that error in loop in the logs of a node, it
seems
How does this work? I have a program that runs a series of alter table
statements, and then does inserts. In some cases, the insert happens
immediately after the alter table statement and the insert fails because
the schema (apparently) has not had time to propagate. I get an
Undefined
