I'm currently operating MySQL on a single node and I want to shift to a high availability setup using Kubernetes. My plan is to deploy MySQL on a four-node on-premises appliance. I've been exploring two replication strategies: 1) Application-level Replication, where MySQL Semi-synchronous replication and Group Replication are my main contenders due to concerns about data loss. I'm leaning towards Group Replication after considering options like the Oracle MySQL Operator and the Percona MySQL Operator. However, if I only want to run MySQL on 3 out of those 4 nodes, how can I provide dynamic storage without manual management? 2) For Disk Replication, I'm evaluating options like OpenEBS, Rook-Ceph, and CubeFS but have performance concerns. I know Ceph allows for distributed storage, which I find appealing. I'd love to hear from anyone with experience or suggestions on what would work best for this setup, especially regarding storage solutions.
1 Answer
It sounds like you're a bit confused about how disk sharing would work in your second replication strategy. Just having a shared PVC doesn’t mean that the MySQL app can access the database files from multiple instances simultaneously. Going with the operator approach is indeed the right choice since it automatically manages replicas and will restore from backups if the entire cluster fails. Personally, I recommend using local storage for the database cluster.
I was thinking of running a MySQL pod with three disk replications, so if one node fails, the pod can be rescheduled using storage from the other nodes. Something like OpenEBS might suit this.