terrymanu commented on issue #39084: URL: https://github.com/apache/shardingsphere/issues/39084#issuecomment-5326704798
Hi @qingleng01, thanks for the detailed follow-up and the attachments. After analyzing them against the 5.5.2 code, we confirm this is a ShardingSphere defect and can classify it without waiting for further reproduction details: metadata loading silently treats an incomplete read as success. The startup behavior chain is: table names are first enumerated over one connection via `DatabaseMetaData#getTables`, then metadata is loaded over another connection via `SELECT ... FROM information_schema.columns WHERE TABLE_SCHEMA=? AND TABLE_NAME IN (...)`, and standalone ShardingSphere-JDBC performs no background refresh afterwards. This chain contains three silent drop points: a table that returns zero rows from the `IN (...)` query is simply absent, with no log entry at all; a `SQLException` from the dialect loader is only logged at DEBUG before falling back to the per-table path, which likewise drops tables silently when the existence probe returns no rows; and if the loading thread is interrupted, the already-merged partial result is returned directly. So whenever any single metadata read at startup is transiently incomplete, the outcome is: the application starts normally, the affected SINGLE tables are permanently missing, no error appears in the logs, and nothing recove rs until the next restart — exactly what you observed (multiple tables missing, persisting for an hour, recovered by restart, other instances unaffected, tables physically present). Which read was incomplete, and why (driver, network, or a transient server-side anomaly on your MySQL build), cannot be determined from the available evidence, but this does not change the classification: ShardingSphere must not silently accept an internally inconsistent result where a table is present in the inventory but absent from the loaded metadata. The same defect exists on current master. Two further notes from your attachments: `sql-parser-ignore-missing-table` is not a defined 5.5.2 property and is silently ignored, so please remove it; and your dependency tree contains both `com.mysql:mysql-connector-j:8.0.33` and the transitive `mysql:mysql-connector-java:5.1.47` (from your internal libraries), so we suggest excluding the latter. If the issue recurs, capturing the results of the `information_schema.columns` query and `DatabaseMetaData#getTables` before restarting would help identify the trigger, and you are welcome to add them here. I suggest `type: bug` with `in: JDBC`, `feature: single`, and `db: MySQL`, severity S3. The fix direction is to compare the expected table set against the actually loaded result after loading, retry or at least log a WARN for the difference, and raise the swallowed dialect-loader exception to WARN; a PR with fault-injection tests is welcome. -- 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]
