terrymanu commented on issue #39084: URL: https://github.com/apache/shardingsphere/issues/39084#issuecomment-5003523454
Hi @qingleng01, thanks for reporting this. This is supported `!SINGLE` usage, but the current evidence is not sufficient to confirm a ShardingSphere bug; we need more information to identify the root cause. In ShardingSphere 5.5.2, `"*.*"` is documented to load all single tables. The stack trace confirms that `risk_feed_result_record` was absent from ShardingSphere’s in-memory schema during SQL binding, before the SQL reached MySQL. During startup, `SingleRule` obtains table names through JDBC `DatabaseMetaData#getTables`; those names are then used to build schema metadata. Restart recovery is consistent with that initialization path being rebuilt successfully, but it does not show why the first instance received or retained incomplete metadata. Please capture the following from an affected instance before restarting it again: - Exact MySQL Server, MySQL Connector/J, and HikariCP versions, plus the complete redacted JDBC URL. - Complete effective ShardingSphere configuration and the filtered dependency tree for ShardingSphere, Connector/J, and HikariCP artifacts. - Startup logs from physical data-source initialization through ShardingSphere data-source creation, followed by the first complete failure stack. - Using the same physical data source and credentials while the failure is active: `Connection#getCatalog()`, `Connection#getSchema()`, and the table names returned by `DatabaseMetaData#getTables(...)`, together with the physical table inventory and DDL for one missing table. - The exact failing SQL and confirmation that the physical table existed before this application instance started. Also, `sql-parser-ignore-missing-table` is not a defined ShardingSphere 5.5.2 configuration property and is not consulted by `SimpleTableSegmentBinder`, so it cannot be relied on to bypass this validation. Please provide this information within 14 days. I suggest applying `status: need more info`, `in: JDBC`, `feature: single`, and `db: MySQL`. If the JDBC metadata probe contains the missing table but ShardingSphere’s schema does not, we can then classify this as a likely metadata initialization bug with a concrete test boundary. The reply above is based on the analysis below; the detailed reasoning is kept here for reference and follow-up contributors. ### Problem Understanding - **Issue:** [#39084](https://github.com/apache/shardingsphere/issues/39084) reports that one ShardingSphere-JDBC 5.5.2 instance lost access to multiple configured single tables after restarting; the failure lasted about one hour and another restart recovered it without configuration changes. (`OBS-1`) - **Topology:** JDBC + Standalone; registry/config center: N/A; storage database: MySQL, version unknown. (`OBS-1`) - **Observed Evidence:** The effective example contains `!SINGLE` with `"*.*"`, while `SimpleTableSegmentBinder.checkTableExists` throws `TableNotFoundException` before physical SQL execution. No deterministic reproduction, exact SQL, MySQL/Connector-J version, complete startup log, or JDBC metadata inventory is available. (`OBS-1`) ### Root Cause - **Observation:** The official 5.5.2 documentation defines `"*.*"` as “Load all single tables,” so the reported rule shape is supported. Source: [ShardingSphere-JDBC 5.5.2 Single Table configuration](https://shardingsphere.apache.org/document/5.5.2/en/user-manual/shardingsphere-jdbc/yaml-config/rules/single/). (`OBS-2`) - **Observation:** `SingleRule` constructs its table mappings from `SingleTableDataNodeLoader`, and the wildcard branch returns the table inventory loaded from the configured data sources. Sources: [kernel/single/core/.../SingleRule.java:73](https://github.com/apache/shardingsphere/blob/5.5.2/kernel/single/core/src/main/java/org/apache/shardingsphere/single/rule/SingleRule.java#L73-L85), [kernel/single/core/.../SingleTableDataNodeLoader.java:59](https://github.com/apache/shardingsphere/blob/5.5.2/kernel/single/core/src/main/java/org/apache/shardingsphere/single/datanode/SingleTableDataNodeLoader.java#L59-L70). (`OBS-3`) - **Observation:** In 5.5.2, table enumeration opens a physical connection and calls `DatabaseMetaData#getTables`. SQL exceptions abort loading, but an incomplete successful result is accepted as the table inventory. Source: [infra/database/core/.../SchemaMetaDataLoader.java:66](https://github.com/apache/shardingsphere/blob/5.5.2/infra/database/core/src/main/java/org/apache/shardingsphere/infra/database/core/metadata/data/loader/type/SchemaMetaDataLoader.java#L66-L77), [SchemaMetaDataLoader.java:106](https://github.com/apache/shardingsphere/blob/5.5.2/infra/database/core/src/main/java/org/apache/shardingsphere/infra/database/core/metadata/data/loader/type/SchemaMetaDataLoader.java#L106-L116). (`OBS-4`) - **Observation:** Schema construction loads metadata for table names exposed by rule attributes, while the binder later requires the referenced table to exist in that constructed schema and throws at line 178 otherwise. Sources: [infra/common/.../GenericSchemaBuilder.java:59](https://github.com/apache/shardingsphere/blob/5.5.2/infra/common/src/main/java/org/apache/shardingsphere/infra/metadata/database/schema/builder/GenericSchemaBuilder.java#L59-L90), [infra/binder/.../SimpleTableSegmentBinder.java:134](https://github.com/apache/shardingsphere/blob/5.5.2/infra/binder/src/main/java/org/apache/shardingsphere/infra/binder/engine/segment/dml/from/type/SimpleTableSegmentBinder.java#L134-L178). (`OBS-5`) - **Observation:** `sql-parser-ignore-missing-table` is absent from the 5.5.2 configuration-property enum, and the binder’s existence check does not consult such a property. Source: [infra/common/.../ConfigurationPropertyKey.java:35](https://github.com/apache/shardingsphere/blob/5.5.2/infra/common/src/main/java/org/apache/shardingsphere/infra/config/props/ConfigurationPropertyKey.java#L35-L131). (`OBS-6`) - **Inference:** The first actionable mismatch is that ShardingSphere’s in-memory schema did not contain the physical single table when binding the SQL. (`INF-1`, from `OBS-1`, `OBS-3`, `OBS-5`) - **Inference:** Startup enumeration or the subsequent schema-build path is relevant and restart recovery is consistent with rebuilding that state, but the evidence cannot distinguish an incomplete JDBC metadata result, an unexpected catalog/schema, physical visibility or grant timing, or a ShardingSphere metadata-loss defect. (`INF-2`, from `OBS-1`, `OBS-3`, `OBS-4`, `OBS-5`) - **Confidence:** Medium for the initialization-path diagnosis; Low for any narrower root-cause claim. ### Problem Analysis - **Issue Type:** Needs More Info (`INF-2`) - **Fast Triage:** The expected wildcard behavior is explicitly documented, but the behavior is not reproducible and repository code cannot prove where the missing table disappeared without the startup JDBC metadata inventory. (`OBS-1`–`OBS-5`) - **Supportability:** This should not be classified as invalid usage because the reported wildcard configuration matches the documented 5.5.2 contract. (`INF-3`, from `OBS-1`, `OBS-2`) - **Duplicate / Prior Fix Check:** No exact same-root-cause issue or fix was found. [#29707](https://github.com/apache/shardingsphere/issues/29707) omitted the required single-table wildcard; [#36385](https://github.com/apache/shardingsphere/issues/36385) concerns a sharded table combined with read/write splitting; [#38524](https://github.com/apache/shardingsphere/pull/38524), [#38623](https://github.com/apache/shardingsphere/pull/38623), and [#38854](https://github.com/apache/shardingsphere/pull/38854) address identifier case or mixed protocol/storage-schema handling rather than this intermittent same-instance startup trigger. (`OBS-7`) - **Blocking Evidence:** Exact dependency/database versions, complete effective configuration, startup logs, the JDBC catalog/schema and `getTables` result during failure, exact SQL/DDL, and physical-table visibility before startup. (`OBS-1`, `INF-2`) - **Label Recommendation:** `status: need more info`, `in: JDBC`, `feature: single`, `db: MySQL` ### Problem Conclusion - **Evidence Confidence:** Medium (`OBS-1`–`OBS-7`, `INF-1`–`INF-3`) - **Impact Scope:** One JDBC application instance; multiple single tables; MySQL storage; SQL binding and metadata initialization paths. (`OBS-1`) - **Topology:** JDBC + Standalone; registry/config center: N/A. (`OBS-1`) - **Issue Type:** Needs More Info (`INF-2`, `INF-3`) - **Recommended Labels:** `status: need more info`, `in: JDBC`, `feature: single`, `db: MySQL` (`OBS-1`, `INF-2`) - **Next Action:** Request the blocking runtime evidence within 14 days. If `DatabaseMetaData#getTables` contains the missing table while ShardingSphere’s schema does not, reclassify as a likely bug and define a focused startup metadata regression test; otherwise investigate the catalog/schema, driver, grants, or physical-table availability shown by the probe. (`INF-1`, `INF-2`) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
