Some of the summary on HA governance feature of ShardingSphere with orchestrator

[Juan Pan <pa...@apache.org>]

Hi community,


I took some time to dig into `orchestrator`. 
Here are some of my thinkings about this product. I'd like to share them with you. 


1. The primary language for this project is `go`. On the other hand, ShardingSphere is programmed by `JAVA`.
2. The license of `orchestrator` is Apache 2.0, which is friendly to collaborate.
3. `orchestrator` is a standalone application that provides web service or command line for discovery, refactoring, and recovery.
4. The feature of the key-values stored Consul or ZooKeeper is just for master discovery currently. 


Here is my conclusion,
In short, `orchestrator` is not the best solution as I expected. Still, we welcome volunteers to take part in this contribution.


If we want to empower ShardingSphere with HA governance, `orchestrator` is not the best solution as I expected. 
My reason is that `orchestrator` is independent of ShardingSphere and deployed as a standalone service to provide replication information. 
Moreover, kv-store based on Zookeeper only has the master information, not the whole relationship among the master node and all the slaves.
Otherwise, the server API can do that instead.
Consequently, ShardingSphere will have a firm rely on its web API (Or KV-values on ZK If we just need master info). 
I can not think of a graceful approach to bring it into ShardingSphere ecosystem.


So, what do you think? Please let me know your innovative ideas.


Best wishes,
Trista




 Juan Pan (Trista)
                         
Senior DBA & PMC of Apache ShardingSphere
E-mail: panjuan@apache.org