Split db-discovery feature from ShardingSphere into separate branch

[zhaojinchao95]

Hi community,

Currently, ShardingSphere database discovery feature provides the function of automatically discovery the master-slave relationship of the database and dynamically correct the status of the data source. It supports MySQL、openGauss database type.

We consider remove this feature, beancase the design of db-discovery and dynamic readwrite-splitting of ShardingSphere seems unreasonable, ShardingSphere readwrite-splitting should kept concise and not should rely master-slave role and read datasource lists of database discovery.

During the actual development and use, we encountered many problems:

• The database discovery does not meet the pluggable architecture of ShardingSphere, it needs to pass the constructed rule to readwrite-splitting.
• ShardingSphere does not provide database high availability, it relies on three-party high-availability solutions to find master-slave topological relationship, there are too many three-party high-availability solutions and they are very complicated, so it is a great challenge for the ShardingSphere database discovery feature.
• The database discovery function awareness may cause the entire read cluster to be unavailable when use ApsaraDB for reading cluster domain names.

Therefore, we intend to remove db-discovery feature in ShardingSphere into a separate branch for maintenance to reduce the cost of understanding and maintaining the main code.

Please voice your opinions as fully as possible. Thank you.

[strongduanmu]

I completely agree with it. These problems in database discovery have limited the development of ShardingSphere. It is time to remove it from the master branch.

[zhaojinchao95]

The issue are finished, so i close it.

[zhaojinchao95]

This issue are finished