MySQL Database on same server Vs different server

Comments

• ollietrex Member

  February 2017

  For big production stuff always on different machines as then there is no CPU or memory contention under load. For smaller stuff I just put it all on the same box as it's cheaper.
• WebProject Host Rep, Veteran

  February 2017

  different server for mysql is normally much better performance, easier for maintenance and backup.
• xyz Member

  February 2017

  In terms of latency and easiness, having them on the same server generally wins. Backups may depend on how you do them, but I think it's largely the same regardless, for the majority of cases.

  Splitting up the two is mostly beneficial when:

  • One server cannot handle the load that your application + DB requires
  • With your way of managing servers / how the provider supplies them, it's easier to separate (e.g. different VM level backups for application and DB)
  • It may help with scaling to certain loads/requirements (e.g. if you want lots of CPU for your application, and lots of RAM for the DB, you may be able to get them better separately rather than trying to have both in the same box)
  • Resource contention between the application and DB is a concern (I'm assuming you're not imposing restrictions otherwise, eg via a VM)

  I'd generally go with the two on the same server unless there's specifically a reason not to. You can always split up the application/DB at a later point in time. Same server has a number of benefits:

  • Cheaper
  • One less server to manage
  • Resource sharing benefits, i.e. if your application uses lots of CPU but little RAM, and the DB is the other way around, sharing the same server can be an efficient way to use available resources. Also, there's no additional resources consumed by a second kernel.
  • One less failure point (the network)
  • Don't have to worry as much about failure modes where one server is down (e.g. how your application should respond if the DB server is dead / network is congested etc) - with one server, it's either all down or all up
  • Better performance: no network latency (plus ability to use Unix sockets for communication instead of running over a full TCP stack)
  • May be easier to keep consistent backups if your application holds any state outside of the DB (in other words, you don't have to worry about mismatched data when restoring from a backup if the two services have their own state)

  DBaaS is a bit different. I've personally felt that if you're comfortable with DBA, it's usually better to manage your own as you get much more flexibility. However, if being a DBA scares you, or you have relatively basic needs, it's probably better to outsource it. Obviously DBaaS is going to be easier than self setup. It also forces you to have a split DB/application setup as well.

  Thanked by 3rm_ k0nsl varwww