[jira] [Updated] (CASSANDRA-16442) Improve handling of failed prepared statement loading

["Thomas Steinmaurer (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-16442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Steinmaurer updated CASSANDRA-16442:
-------------------------------------------
    Fix Version/s: 3.11.x

> Improve handling of failed prepared statement loading
> -----------------------------------------------------
>
>                 Key: CASSANDRA-16442
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-16442
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Thomas Steinmaurer
>            Priority: Normal
>             Fix For: 3.11.x
>
>
> In an internal DEV cluster, when going from 3.0 to 3.11 we have seen the following WARN logs constantly upon Cassandra startup.
> {noformat}
> ...
> WARN [main] 2021-02-05 09:25:06,892 QueryProcessor.java:160 - prepared statement recreation error: SELECT n,v FROM "Ts2Volatile60Min" WHERE k=? LIMIT ?;
> WARN [main] 2021-02-05 09:25:06,895 QueryProcessor.java:160 - prepared statement recreation error: INSERT INTO "Ts2Final01Min" (k,n,v) VALUES (?,?,?) USING TIMESTAMP ?;
> ...
> {noformat}
> I guess 3.11 tries to pre-load prepared statements for tables which don't exist anymore. On how we got into this situation was our fault I think (Cas 3.0 => Upgrade 3.11 => Downgrade 3.0 => with 3.0 some tables got dropped => Upgrade 3.11.10).
> Still, perhaps there is room for improvement when it comes to loading persisted prepared statements, which might fail.
> I thought about:
> * An additional {{nodetool}} option to wipe the persisted prepared statement cache
> * Perhaps even make the startup code smarter in a way, when loading of a prepared statement fails, due to a table not being available anymore, then auto-wipe such entries from the {{prepared_statements}} system table
> To get rid of the WARN log, I currently need to work directly on the "prepared_statements" system table, but I don't know if it is safe to run e.g. a TRUNCATE statement, thus currently, it seems we need to take each node offline, execute a Linux {{rm}} command on SSTables for the system table.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org