Section 1: Proxy&Metrics port should be consider as a unique number in the own server, whether there is only one process or many processes. So it may be not a globally configuration. Use command params or -D for jvm options will be better. Section 2: Orchestration config is for proxy/jdbc to find the zk server for configuration details, so this config is not suitable to persist to zk. Just like Section 1, Use command params or -D for jvm options will be better. Section 3: According to our design, logic schema will be a nice approach for a group configuration, rather then a proxy node or machine.
在 2020-08-07 10:55:55，"Myth" <[email protected]> 写道： >+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]
