Most of the time orchestrator only reads status from your topologies. Default configuration is to poll each instance once per minute.
orchestrator will connect to your topology servers, and will cap number of concurrent connections.
You may use orchestrator to refactor your topologies: move replicas around and change the replication tree. orchestrator will do its best to:
- Make sure you only move an instance to a location where it is valid for it to replicate (e.g. that you don't put a 5.5 server below a 5.6 server)
- Make sure you move an instance at the right time (ie the instance and whichever affected servers are not lagging badly, so that operation can completely in a timely manner).
- Do the math correctly: stop the replica at the right time, roll it forward to the right position,
CHANGE MASTERto the correct location & position.
The above is well tested.
You may use orchestrator to failover your topologies. You will be concerned that:
orchestratordoesn't failover when there is no need.orchestratordoes fail over when there is a need.- A failover doesn't lose too many servers
- Failover ends with a consistent topology
Failovers are inherently tied to your deployments through hooks.
There's always risk with failovers. Make sure to test them.
Please make sure to read the LICENSE, and especially the "WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND" part.