qingleng01 commented on issue #39084: URL: https://github.com/apache/shardingsphere/issues/39084#issuecomment-5053907571
> 你好[@qingleng01](https://github.com/qingleng01)感谢您的反馈。这是支持的`!SINGLE`操作，但目前的证据不足以确认这是 ShardingSphere 的一个 bug；我们需要更多信息来确定根本原因。 > > 在 ShardingSphere 5.5.2 中，`"*.*"`文档显示会加载所有单个表。堆栈跟踪证实，`risk_feed_result_record`在 SQL 绑定期间（即 SQL 到达 MySQL 之前），ShardingSphere 的内存模式中缺少该表。启动期间，`SingleRule`通过 JDBC 获取表名`DatabaseMetaData#getTables`；这些表名随后用于构建模式元数据。重启恢复过程表明初始化路径已成功重建，但并未解释为什么第一个实例接收或保留了不完整的元数据。 > > 请在重启受影响的实例之前，从该实例中获取以下信息： > > * MySQL 服务器、MySQL Connector/J 和 HikariCP 的确切版本，以及完整的已编辑 JDBC URL。 > * 完整的有效 ShardingSphere 配置以及 ShardingSphere、Connector/J 和 HikariCP 工件的过滤依赖关系树。 > * 从物理数据源初始化到 ShardingSphere 数据源创建的启动日志，以及第一个完整的故障堆栈。 > * 在故障发生期间，使用相同的物理数据源和凭据：`Connection#getCatalog()`，，`Connection#getSchema()`以及返回的表名`DatabaseMetaData#getTables(...)`，以及一个缺失表的物理表清单和 DDL。 > * 出错的 SQL 语句的确切信息，以及确认物理表在应用程序实例启动之前就已存在。 > > 此外，`sql-parser-ignore-missing-table`它不是 ShardingSphere 5.5.2 中定义的配置属性，也不会被查询`SimpleTableSegmentBinder`，因此不能依赖它来绕过此验证。 > > 请在 14 天内提供此信息。我建议应用以下方法`status: need more info`：`in: JDBC`[此处应列出具体方法]。如果 JDBC 元数据探测包含缺失的表，但 ShardingSphere 的模式中不包含，则我们可以将其归类为可能存在的元数据初始化错误，并设定具体的测试边界。`feature: single``db: MySQL` > > 以上回复基于以下分析；详细论证过程保留在此处，供参考和后续贡献者参考。 > > ### 问题理解 > * **问题：** [#39084](https://github.com/apache/shardingsphere/issues/39084)`OBS-1`报告称，一个 ShardingSphere-JDBC 5.5.2 实例在重启后丢失了对多个已配置单表的访问权限；故障持续约一小时，再次重启后恢复正常，无需更改任何配置。 > * **拓扑结构：** JDBC + 独立模式；注册表/配置中心：无；存储数据库：MySQL，版本未知。（`OBS-1`） > * **观察到的证据：**有效示例包含`!SINGLE`with `"*.*"`，但在实际执行 SQL 之前`SimpleTableSegmentBinder.checkTableExists`抛出异常`TableNotFoundException`。没有可确定性复现的方法、确切的 SQL、MySQL/Connector-J 版本、完整的启动日志或 JDBC 元数据清单。( `OBS-1`) > > ### 根本原因 > * **观察：**官方 5.5.2 文档将其定义`"*.*"`为“加载所有单表”，因此所报告的规则结构是受支持的。来源：[ShardingSphere-JDBC 5.5.2 单表配置](https://shardingsphere.apache.org/document/5.5.2/en/user-manual/shardingsphere-jdbc/yaml-config/rules/single/)。（`OBS-2`） > * **观察：** `SingleRule`它根据`SingleTableDataNodeLoader`配置的数据源构建表映射，并且通配符分支返回从已配置数据源加载的表清单。来源：[kernel/single/core/.../SingleRule.java:73，kernel/single/core](https://github.com/apache/shardingsphere/blob/5.5.2/kernel/single/core/src/main/java/org/apache/shardingsphere/single/rule/SingleRule.java#L73-L85) /.../ [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`) > * **观察：**在 5.5.2 版本中，表枚举会打开一个物理连接并调用 SQL 异常。SQL 异常会导致加载中止，但即使加载`DatabaseMetaData#getTables`成功，也会接受不完整的表清单结果。来源：[infra/database/core](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:66，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` > * **观察：**模式构建会加载规则属性公开的表名的元数据，而绑定器随后要求引用的表存在于已构建的模式中，否则会在第 178 行抛出异常。来源：[infra/common/.../GenericSchemaBuilder.java:59，infra/binder](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) /.../ [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`) > * **观察：** `sql-parser-ignore-missing-table` 5.5.2 配置属性枚举中缺少此属性，并且绑定器的存在性检查不会查询此属性。来源：[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`) > * **推断：**第一个可操作的不匹配之处在于，ShardingSphere 的内存模式在绑定 SQL 时未包含物理单表。（`INF-1`，来自`OBS-1`，，`OBS-3`）`OBS-5` > * **推断：**启动枚举或后续的模式构建路径是相关的，重启恢复与重建该状态一致，但证据无法区分不完整的 JDBC 元数据结果、意外的目录/模式、物理可见性或授权时间，还是 ShardingSphere 元数据丢失缺陷。（，`INF-2`来自`OBS-1`，，，`OBS-3`）`OBS-4``OBS-5` > * **置信度：**初始化路径诊断为中等；任何更具体的根本原因主张的置信度较低。 > > ### 问题分析 > * **问题类型：**需要更多信息（`INF-2`） > * **快速排查：**预期的通配符行为已明确记录，但该行为无法重现，且在没有启动 JDBC 元数据清单的情况下，代码库无法证明缺失的表在哪里消失。（`OBS-1`- `OBS-5`） > * **支持性：**这不应被归类为无效用法，因为所报告的通配符配置符合文档中记录的 5.5.2 版本约定。（`INF-3`，来自`OBS-1`，`OBS-2`） > * **重复/先前修复检查：**未发现完全相同的根本原因问题或修复方案。[#29707](https://github.com/apache/shardingsphere/issues/29707)遗漏了必需的单表通配符；[#36385](https://github.com/apache/shardingsphere/issues/36385)涉及分片表以及读/写分离；[#38524](https://github.com/apache/shardingsphere/pull/38524)、[#38623](https://github.com/apache/shardingsphere/pull/38623)和[#38854](https://github.com/apache/shardingsphere/pull/38854)解决的是标识符大小写或混合协议/存储模式处理问题，而不是这种间歇性的同一实例启动触发问题。( `OBS-7`) > * **阻塞证据：**确切的依赖项/数据库版本、完整的有效配置、启动日志、JDBC 目录/模式及`getTables`故障结果、确切的 SQL/DDL 语句，以及启动前物理表的可见性。（`OBS-1`，`INF-2`） > * **** 标签**推荐**：`status: need more info`，，，`in: JDBC``feature: single``db: MySQL` > > ### 问题结论 > * **证据置信度：**中等（`OBS-1`– `OBS-7`，`INF-1`– `INF-3`） > * **影响范围：**一个 JDBC 应用程序实例；多个单表；MySQL 存储；SQL 绑定和元数据初始化路径。（`OBS-1`） > * **拓扑结构：** JDBC + 独立；注册表/配置中心：不适用。（`OBS-1`） > * **问题类型：**需要更多信息（`INF-2`，`INF-3`） > * **** 推荐**标签**：`status: need more info`，，，（，`in: JDBC`）`feature: single``db: MySQL``OBS-1``INF-2` > * **下一步操作：**在 14 天内请求阻塞运行时证据。如果该`DatabaseMetaData#getTables`证据包含缺失的表，而 ShardingSphere 的模式中没有，则将其重新分类为可能的 bug，并定义一个有针对性的启动元数据回归测试；否则，调查探测结果显示的目录/模式、驱动程序、授权或物理表可用性。（`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]
