@Rocky I have errors:

I'm ready to help! Please provide the specific error message or log output you're seeing, and I'll do my best to troubleshoot it for you.

@Rocky I've dropped catalog and its objects and someone tries to refresh cached objects and it fails 2026-07-08 213311.151+05:00 WARN (starrocks-mysql-nio-pool-18638|571325) [StmtExecutor.execute():984] execute Exception, sql: /* ApplicationName=DataGrip 2025.3.5 */ SHOW INDEX FROM

reset__detail

FROM

ods_lil

com.starrocks.sql.analyzer.SemanticException: Getting analyzing error. Detail message: Unknown database 'ods_loyalty'. at com.starrocks.common.ErrorReport.reportSemanticException(ErrorReport.java:75) ~[starrocks-fe.jar:?] at com.starrocks.common.ErrorReport.reportSemanticException(ErrorReport.java:67) ~[starrocks-fe.jar:?] at com.starrocks.sql.common.MetaUtils.checkDbNullAndReport(MetaUtils.java:68) ~[starrocks-fe.jar:?] at com.starrocks.qe.ShowExecutor$ShowExecutorVisitor.visitShowIndexStatement(ShowExecutor.java:2418) ~[starrocks-fe.jar:?] at com.starrocks.qe.ShowExecutor$ShowExecutorVisitor.visitShowIndexStatement(ShowExecutor.java:321) ~[starrocks-fe.jar:?] at com.starrocks.sql.ast.ShowIndexStmt.accept(ShowIndexStmt.java:75) ~[starrocks-fe.jar:?] at com.starrocks.sql.ast.AstVisitor.visit(AstVisitor.java:102) ~[starrocks-fe.jar:?] at com.starrocks.qe.ShowExecutor.execute(ShowExecutor.java:318) ~[starrocks-fe.jar:?] at com.starrocks.qe.StmtExecutor.handleShow(StmtExecutor.java:2205) ~[starrocks-fe.jar:?] at com.starrocks.qe.StmtExecutor.execute(StmtExecutor.java:891) ~[starrocks-fe.jar:?] at com.starrocks.qe.ConnectProcessor.executeQueryAttempt(ConnectProcessor.java:535) ~[starrocks-fe.jar:?] at com.starrocks.qe.ConnectProcessor.runWithParserStageRetry(ConnectProcessor.java:433) ~[starrocks-fe.jar:?] at com.starrocks.qe.ConnectProcessor.handleQuery(ConnectProcessor.java:370) ~[starrocks-fe.jar:?] at com.starrocks.qe.ConnectProcessor.dispatch(ConnectProcessor.java:746) ~[starrocks-fe.jar:?] at com.starrocks.qe.ConnectProcessor.processOnce(ConnectProcessor.java:1137) ~[starrocks-fe.jar:?] at com.starrocks.mysql.nio.ReadListener.lambda$handleEvent$0(ReadListener.java:71) ~[starrocks-fe.jar:?] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?] at java.lang.Thread.run(Thread.java:840) ~[?:?]

The error you are seeing occurs because an external tool—specifically DataGrip (as indicated by the

ApplicationName=DataGrip

in the SQL comment)—is attempting to refresh its internal metadata cache for a catalog or database that no longer exists in StarRocks. Why this is happening: 1. Metadata Removal: When you executed

DROP CATALOG

, StarRocks removed the catalog and all its associated databases/tables from its internal metadata. 2. Stale Client Cache: DataGrip maintains a local "Database Explorer" tree. It doesn't immediately know the catalog is gone and will periodically run background queries (like

SHOW INDEX

or

SHOW TABLES

) to keep its UI up to date. 3. Analyzer Failure: When DataGrip sends

SHOW INDEX FROM reset__detail FROM ods_lil

, the StarRocks Front End (FE) tries to resolve the database

ods_lil

. Since the catalog containing it was dropped, the FE can't find the database and throws a

SemanticException: Unknown database

. Why the name mismatch (

ods_lil

vs

ods_loyalty

)? The mismatch in the log (SQL references

ods_lil

but error mentions

ods_loyalty

) usually happens for one of two reasons: * Session Context: Your DataGrip session may still be "stuck" with its default database set to

ods_loyalty

. When any metadata query runs, the analyzer checks the session context, finds the old database name, and fails. * IDE Mapping: DataGrip sometimes maps internal identifiers to names; if the metadata is partially deleted or the session is stale, the error reporting might surface the last known valid database name from the session state. How to resolve: 1. Refresh DataGrip: Right-click your DataGrip data source and select Refresh (or Force Refresh). This forces the IDE to clear its local cache and realize the catalog/databases are gone. 2. Switch Session Context: If you are running queries manually in a console, ensure you switch back to a valid catalog:

sql
    SET CATALOG default_catalog;
    USE default_db; -- replace with an existing database

3. Reconnect: The simplest way to clear stale session state in both the IDE and the StarRocks FE is to close the connection in DataGrip and open a new one. The

WARN

logs in StarRocks will stop as soon as the client (DataGrip) stops sending requests for the deleted objects. References • data_source/catalog/unified_catalog.md • sql-reference/sql-statements/Catalog/SET_CATALOG.md • sql-reference/sql-statements/Catalog/DROP_CATALOG.md • data_source/catalog/default_catalog.md • data_source/catalog/hive_catalog.md • data_source/catalog/catalog_overview.md

@Rocky can I somehow manage it from starrocks to kill that session or somethin like that

Yes, you can manage and terminate these sessions directly from StarRocks using the

KILL

command. 1. Identify the Session ID Based on your log entry

(starrocks-mysql-nio-pool-18638|571325)

, the number

571325

is likely the Connection ID. To confirm this and see all active sessions, run:

sql
SHOW FULL PROCESSLIST;

Look for the row where the

User

is your DataGrip user and the

Host

matches your machine's IP. You will see a column named

Id

. 2. Kill the Connection To force-close the connection from the server side, use the

KILL

command with that ID:

sql
KILL 571325;

*

KILL <id>

(or

KILL CONNECTION <id>

): This terminates the entire connection and any currently running query. This is what you want to stop DataGrip from sending more background "refresh" requests on that specific pipe. *

KILL QUERY <id>

: This only stops the current SQL being executed but leaves the connection open. Note on DataGrip behavior If DataGrip is configured to automatically reconnect (which is the default), it might simply open a new session and start the refresh process again. To stop this permanently, you should Refresh or Test Connection within DataGrip itself so it updates its local metadata to reflect that the catalog has been dropped. References • administration/management/resource_management/Query_management.md • sql-reference/sql-statements/cluster-management/nodes_processes/KILL.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROCESSLIST.md References • administration/management/resource_management/Query_management.md • sql-reference/sql-statements/cluster-management/nodes_processes/KILL.md • faq/operation_maintenance_faq.md • administration/management/monitor_manage_big_queries.md • administration/management/graceful_exit.md

@Rocky restarting fe still cant help?

Restarting the FE will not permanently solve this problem. Here is why: 1. Client-Side Trigger: The error log explicitly contains

/_ ApplicationName=DataGrip ... _/

. This means the query is being generated by a specific client (the DataGrip IDE) or a user session using that IDE. 2. Auto-Reconnect: When you restart the FE, it kills all current connections. However, most modern IDEs like DataGrip are configured to automatically reconnect as soon as the database is back online. 3. Stale Cache: Once DataGrip reconnects, its internal "Database Explorer" tree will still think the

ods_lil

or

ods_loyalty

databases exist. It will then automatically re-send those metadata queries (

SHOW INDEX

,

SHOW TABLES

, etc.) to refresh its UI, leading to the same

Unknown database

error in your logs. Why you see

Unknown database 'ods_loyalty'

when the SQL says

ods_lil

? This usually happens because the session's "current database" context is set to

ods_loyalty

. When the FE analyzes any incoming SQL, it validates the current session context. Since you dropped the catalog containing that database, the session is now pointing to a non-existent location, and the analyzer fails before it even finishes processing the

SHOW INDEX

command. Recommended Steps: * Don't restart the FE: It is unnecessary and causes a small outage for other users. * Force Refresh DataGrip: The person using DataGrip must right-click their connection and select Refresh or Force Refresh. This tells the IDE: "Forget everything you know about the schema and fetch it again from StarRocks." * Kill the specific session: As mentioned before, use

SHOW PROCESSLIST

to find the ID and

KILL <id>

. If the errors come back immediately, it confirms that a client is auto-reconnecting. * Check for automated scripts: If no human is using DataGrip, check if there is a background service (like a BI tool, an ETL job, or a monitoring agent) using a DataGrip JDBC driver that is still pointing to the old catalog. In short, the "fix" must happen on the client side because the server (StarRocks) is already correctly reporting that the data is gone. References • administration/management/FE_configuration.md • administration/Meta_recovery.md

@Rocky can I catch which users datagrip runs that?

Yes, you can identify exactly which user and machine (IP address) are triggering these errors using the following methods: 1. Check active sessions (easiest) If the DataGrip client is still connected (which it usually is, even if queries are failing), run:

sql
SHOW FULL PROCESSLIST;

Look for the row where the

Id

column matches the connection ID from your log (

571325

). * User: Shows the StarRocks account name used. * Host: Shows the IP address and port of the machine running DataGrip. * Info: You will likely see the SQL comment

/_ ApplicationName=DataGrip ... _/

. 2. Search for the DataGrip signature If there are many connections, you can query the

information_schema

to filter for DataGrip specifically:

sql
SELECT Id, User, Host, Db, Info 
FROM information_schema.processlist 
WHERE Info LIKE '%DataGrip%' 
   OR Id = 571325;

3. Check the Audit Log (if the session is closed) If the connection is intermittent and you can't catch it with

SHOW PROCESSLIST

, you can check the FE audit log on your StarRocks leader node: 1. Go to your FE log directory (usually

starrocks/fe/log/

). 2. Search the

fe.audit.log

for the specific timestamp or the database name:

bash
    grep "ods_lil" fe.audit.log | grep "DataGrip"

The audit log records every SQL attempt, including the User and the Client IP, even if the query fails with a

SemanticException

. Summary of what to look for: * If you find the IP: You can identify the person's machine. * If you find the User: You can see which credentials they are using (e.g.,

root

,

developer_user

). Once identified, that person needs to Refresh their DataGrip connection to clear the stale metadata cache. References • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROCESSLIST.md • administration/management/resource_management/Query_management.md • faq/operation_maintenance_faq.md • administration/management/logging.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_RUNNING_QUERIES.md • administration/management/monitor_manage_big_queries.md • sql-reference/sql-statements/cluster-management/nodes_processes/KILL.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md • sql-reference/information_schema/verbose_session_variables.md • sql-reference/information_schema/session_variables.md • using_starrocks/running_queries.md • administration/management/graceful_exit.md • administration/Meta_recovery.md • administration/management/FE_configuration.md • sql-reference/sql-statements/Catalog/DROP_CATALOG.md