+1. good idea,i will follow
------------------ ???????? ------------------
??????:
"dev"
<[email protected]>;
????????: 2020??8??6??(??????) ????11:42
??????: "dev"<[email protected]>;
????: [DISCUSS] Discussion on ShardingSphere configuration
Hi, community
For the current configurations of ShardingSphere, the following issues
need to be discussed:
### Proxy and Metrics port configuration
Based on the unified configuration design, we consider the unified port
configuration mode. There are the following three methods??
1. Pass directly through the shell, and the Main method uses args to
receive (strict parameter order is required)
2. The environment variable ?? -D ??
3. Configuration files (the existing way of Metrics)
### The persistent configurations of the config center may not be
reasonable. Consider which configuration items need to be written to the
config center and which are stored locally
The existing configuration items are as follows:
1. orchestration (not persisted)
2. authentication (all persisted)
3. metrics ( all persisted )
4. cluster ( all persisted )
5. props ( all persisted )
6. schemas ( all persisted )
7. proxy port (not persisted)
Each configuration item needs to be subdivided separately. Consider whether
all configurations need to be written into the config center. It is
recommended that only the data that is needed and can be dynamically
modified will be written into the config center.
### How to persist permission data
Now the proxy permission data is persisted in the config center, and it is
a global configuration. As long as it is modified, the proxy cluster takes
effect. There are certain risks in this way. If the permission is leaked,
the cluster will be at risk. so, there are some suggestions:
1. Consider the independent configuration permission of each proxy
2. Considering that at least the machine permissions are required, then use
the proxy command to operate
**welcome your discussion!**
--
Haoran Meng
[email protected]
