Handle unplanned workload changes by dynamically scaling out with more nodes. Optimize resource usage by scaling back nodes.
Let us worry about the mechanics to get it done ,including reconfiguring load balancer configurations to match the topology changes.
Add a slave to your cluster with the master dataset automatically primed, and asynchronous replication running. Use a delayed slave as a live backup node, or as a loosely coupled reporting server that does not impact cluster performance.
Efficiently duplicate your production database to support application development and testing activities with the latest dataset.
Other scenarios include live migrations to new hardware or datacenters, troubleshooting of production datasets in the safety of a test environment or upgrade/patch test of new database software versions.
No, all you need are clean VMs with the OS installed. ClusterControl will connect to the host, install the necessary software and make sure it synchronises with the rest of the cluster.
If the load balancers are managed by ClusterControl, then yes. The list of database nodes is maintained to reflect any topology changes. If you deployed the load balancer using ClusterControl, it also has health checks customised for the cluster type.
There are a few reasons. Long-running reporting/OLAP type queries on a Galera node might slow down an entire cluster, if the reporting load is so intensive that the node has to spend considerable effort coping with it. So reporting queries can be sent to a standalone server, effectively isolating Galera from the reporting load. In a belts and suspenders approach, an asynchronous slave can also serve as a remote live backup.
Yes, you can easily create an autoscaling advisor to monitor your custom performance metrics and make scaling decisions based on that. One example of how to scale a replication setup can be found here.