I'm in the process of moving multiple databases (including PostgreSQL, MariaDB, MySQL, and H2) from virtual machines to operators on our Kubernetes cluster. We're happy with Crunchy Postgres Operator for PostgreSQL since it integrates well with the cluster, but we're still deciding on the right operator for our MariaDB and MySQL databases. Here are our key requirements: we need high availability with multiple replicas and node anti-affinity, cloud backups to S3, a smooth restore process with point-in-time recovery and cloning capabilities, solid documentation, and deployment through Helm charts. It would also be great to have monitoring features, like a Prometheus exporter. Can anyone share their experiences or recommendations for MariaDB/MySQL operators? Thanks!
3 Answers
I'll skip the usual warnings about running databases in Kubernetes and suggest the [mariadb-operator](https://github.com/mariadb-operator/mariadb-operator). I've heard that enterprise support might be coming soon, so if you're interested in that, this could be a good option. While I’m not a fan of using Kubernetes CRDs for DB management, the operator gives you that flexibility. Consider looking into MaxScale if you need load balancing. I've also heard positive things about the Percona operator and Vitess if your use case needs sharding.
Hey! Just so you know, I’m the maintainer of the mariadb-operator. You should definitely check it out [here](https://github.com/mariadb-operator/mariadb-operator). Right now, cloning isn't supported, but we're working on adding `VolumeSnapshot` support in the next release. If you have any questions about it, I’d be happy to help!
I tried the Vitess operator but ended up switching to a managed MySQL server on Azure! It was just too complicated for a single app. If you choose Vitess, make sure to understand its architecture and user settings, especially regarding security.
That makes sense! Vitess does have a steep learning curve.
What’s the complexity level of Vitess? Is it easy to set up?