>
> We are on cassandra 3.11 , we are using G1GC and using 16GB of heap.
>
Which exact version of C* is it again?
> WARN [MessagingService-Incoming-/10.X.X.X] 2020-02-18 14:21:47,115
> IncomingTcpConnection.java:103 - UnknownColumnFamilyException reading from
> socket; closing
>
This is expected because your app is trying to read the MV you just dropped.
ERROR [MutationStage-9] 2020-02-18 14:21:47,267 Keyspace.java:593 -
Attempting to mutate non-existant table
7bb4b2d2-8622-11e8-a44b-a92f2dd93ff1
>
>
Any view update transactions which are already in-flight will fail. Again,
this is expected since the MV updates are not synchronous with the base
table updates.
WARN [BatchlogTasks:1] 2020-02-18 14:21:53,786
BatchlogManager.java:252 - Skipped batch replay of
a19c6480-5294-11ea-9e09-3948c59ad0f5 due to {}
>
>
As above, this is expected since the MV updates which are already in the
queue will fail to apply because the MV got dropped.
WARN [HintsDispatcher:6737] 2020-02-18 14:22:24,932
HintsReader.java:237 - Failed to read a hint for /10.X.X.X:
f75e58e8-c255-4318-a553-06487b6bbe8c - table with id
7bb4b2d2-8622-11e8-a44b-a92f2dd93ff1 is unknown in file
f75e58e8-c255-4318-a553-06487b6bbe8c-1582060925656-1.hints
>
>
This is also expected. It won't be able to read the hint for a non-existent
MV.
So where to from here? The symptoms you described indicate that you haven't
updated your app *before* you dropped the MVs. That is key here -- your app
shouldn't be issuing reads for the MV since your intention is to drop it.
What I think happened is that the nodes were backed up with read requests
for the MV which no longer exists.
Can you confirm that you have changed your application so it is not
supposed to issue reads to the MV? You shouldn't drop MVs if you're still
going to issue read requests from them just like you shouldn't drop tables
your app is still expected to access. I hope that makes sense. Cheers!
