dangmingyang commented on issue #37014: URL: https://github.com/apache/shardingsphere/issues/37014#issuecomment-3494372065
> The connection failure you experienced occurs because ShardingSphere needs to establish a database connection during startup to determine the database type. This happens in the DatabaseTypeEngine.getStorageType() method, which calls dataSource.getConnection() to inspect database metadata. > > However, this connection check serves a specific purpose: database type detection, not comprehensive health monitoring of data sources. > > ShardingSphere's Design Philosophy: Why It Does Not Manage Data Source State > > ShardingSphere follows the Database Plus design philosophy, positioning itself as an enhancement layer on top of existing databases rather than a replacement for database management infrastructure. This design choice is intentional and follows several important software engineering principles. > > Separation of Concerns > > ShardingSphere's Core Responsibilities: > > * Data sharding and routing > * Read-write separation > * Data encryption and masking > * Distributed transactions > * SQL parsing and execution > > Connection Pool Responsibilities: > > * Connection lifecycle management > * Health monitoring and failure detection > * Connection pool size management > * Performance optimization > > Database Responsibilities: > > * Data persistence > * Transaction management > * Storage engine operations > > This clear separation ensures that each component focuses on what it does best, without unnecessary overlap or complexity. > > Conclusion > > The connection failure you experienced during restart is an infrastructure issue that should be handled at the container orchestration level, not by ShardingSphere itself. This is consistent with distributed systems best practices, where each component maintains clear boundaries and responsibilities. > > In production environments, database connectivity should be managed through: > > * Container orchestration startup dependencies > * Service discovery mechanisms > * Appropriate health checks at the infrastructure level > * Database connection pooling configuration > > This design allows ShardingSphere to remain focused on its core mission: providing powerful data enhancement capabilities while maintaining architectural simplicity and ecosystem compatibility. But does this bring about a problem: after I have registered a Storage in my shardingsphere-proxy, if the database corresponding to this Storage is deprecated or its IP address is changed one day, will my shardingsphere-proxy fail to start normally all the time when it restarts? If so, can I manually delete or deregister this storage from the database used by my shardingsphere-proxy? -- 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]
