回复：[DISCUSS] Discussion on ShardingSphere configuration

[Myth <xi...@qq.com>]

+1. good idea,i will follow




------------------ 原始邮件 ------------------
发件人:                                                                                                                        "dev"                                                                                    <menghaoranss@gmail.com&gt;;
发送时间:&nbsp;2020年8月6日(星期四) 晚上11:42
收件人:&nbsp;"dev"<dev@shardingsphere.apache.org&gt;;

主题:&nbsp;[DISCUSS] Discussion on ShardingSphere configuration



Hi, community

For the current configurations of ShardingSphere,&nbsp; 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
menghaoranss@gmail.com

Re:回复：[DISCUSS] Discussion on ShardingSphere configuration

[KimmKing <ki...@apache.org>]

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" <xi...@qq.com> 写道：
>+1. good idea,i will follow
>
>
>
>
>------------------&nbsp;原始邮件&nbsp;------------------
>发件人:                                                                                                                        "dev"                                                                                    <menghaoranss@gmail.com&gt;;
>发送时间:&nbsp;2020年8月6日(星期四) 晚上11:42
>收件人:&nbsp;"dev"<dev@shardingsphere.apache.org&gt;;
>
>主题:&nbsp;[DISCUSS] Discussion on ShardingSphere configuration
>
>
>
>Hi, community
>
>For the current configurations of ShardingSphere,&nbsp; 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
>menghaoranss@gmail.com