7

I have an Kubernetes environment running multipe applications (services). Now i'm a little bit confused how to setup the MySQL database instance(s).

According to different sources each microservice should have there own database. Should i create a single MySQL statefulset in HA mode running multiple databases OR should i deploy a separate MySQL instance for each application (service) running one database each.

My first thought would be the first option hence where should HA oterwise be usefull for? Would like to hear some differente views on this.

EntonoX
  • 81
  • 1
  • 6

1 Answers1

23

Slightly subjective question, but here's what we have setup. Hopefully, that will help you build a case. I'm sure someone would have a different opinion, and that might be equally valid too:

We deploy about 70 microservices, each with it's own database ("schema"), and it's own JDBC URL (defined via a service). Each microservice has it's own endpoint and credentials that we do not share between microservices. So in effect, we have kept the design to be completely independent across the microservices as far as the schema is concerned.

Deployment-wise, however, we have opted to go with a single database instance for hosting all databases (or "schemas"). While technically, we could deploy each database on its own database instance, we chose not to do it for few main reasons:

  1. Cost overhead: Running separate database instances for each microservice would add a lot of "fixed" costs. This may not be directly relevant to you if you are simply starting the database as a MySQL Docker container (we use a separate database service, such as RDS or Google Cloud SQL). But even in the case of MySQL as a Docker container, you might end up having a non-trivial cost if you run, for example, 70 separate containers one per microservice.
  2. Administration overhead: Given that databases are usually quite involved (disk space, IIOPs, backup/archiving, purge, upgrades and other administration activities), having separate database instances -- or Docker container instances -- may put a significant toll on your admin or operations teams, especially if you have a large number of microservices
  3. Security: Databases are usually also critical when it comes to security as the "truth" usually goes in the DB. Keeping encryption, TLS configuration and strengths of credentials aside (as they should be of utmost importance regardless of your deployment model), security considerations, reviews, audits and logging will bring in significant challenges if your databases instances are too many.
  4. Ease of development: Relatively less critical in the grand scheme of things, but significant, nonetheless. Unless you are thinking of coming up with a different model for development (and thus breaking the "dev-prod parity"), your developers may have a hard time figuring out the database endpoints for debugging even if they only need that information once-in-a-while.

So, my recommendation would be to go with a single database instance (Docker or otherwise), but keep the databases/schemas completely independent and inaccessible by the any microservice but the "owner" microservice.

If you are deploying MySQL as Docker container(s), go with a StatefulSet for persistence. Define an external pvc so that you can always preserve the data, no matter what happens to your pods or even your cluster. Of course, if you run 'active-active', you will need to ensure clustering between your nodes, but we do run it in 'active-passive' mode, so we keep the replica count to 1 given we only use MySQL Docker container alternative for our test environments to save costs of external DBaaS service where it's not required.

Kartik Pandya
  • 2,718
  • 2
  • 14
  • 28
  • Thanks for this excellent answer! Your mentions about cost overhead, administration overhead and security seems enough to go for the single database instance solution. With the last comment about active-active you mean HA clusters? – EntonoX Aug 13 '18 at 06:22
  • Yes. Both 'Active-Passive' and 'Active-Active' would be HA solution, but 'Active-Active' would also additionally give you load balancing, which may or may not be what you are looking for. – Kartik Pandya Aug 13 '18 at 20:52
  • just want to mention some advantage if you go with multi DB sometimes your applications use different versions of db so separate your db servers will be better if you planning to upgrade your application and it use the latest features of db so we back to 1 i know managing will be hard for multi db but not in all operations actually it depends on ur policy of management it's easier to move any part of your application and reuse it when everything is separated If you want to go with multi db just make sure you apply a fully automated management and it will be easier than managing one server – Technology-Geek Feb 11 '23 at 16:45