8

A similar question turned into opinion soup over here: So maybe there's no 'right' answer to this, but I want to check with the community.

My client is about to launch a TV advert. They are expecting traffic in the 7-digit department over the coming month. My job is to ensure the server does not fall over.

My question: is it worthwhile to split the MySQL database onto a separate server, which only serves the database. I then want to have multiple servers which contain the codebase and serve apache, interfacing with the database box. All will be virtual containers.

I do NOT (think) I want to use multiple DB servers - seems it will introduce unnecessary complexity and potential errors/bottlenecks.

Am I wrong? Would welcome some experience opinions on this. Thanks.

16

We've used a separate MySQL server in several instances where the shops were facing high traffic. There are a couple of advantages to it

  1. Dedicated database servers can be tweaked to the specific needs of MySQL which are different from a webserver
  2. It's easy to add a second (load balanced) database server to the cluster when needed
  3. When your database goes down it doesn't crash the frontend so you can display a decent warning or error page.

When Magento is properly cached with Varnish or any other FPC extension the main bottleneck will be the database from what I have experienced. The real power will be required for your database. In this way you can start out with a relatively small web server and invest more in the database server.

12

Security:

In addition to Sander's answer, I would add that at certain levels of PCI compliance this is a requirement:

Separate Web and Database Servers CHD is stored en mass in the database, making it a high-value target to an attacker. Separate database server means that access can be strictly controlled (limited exposure). Required by Section 1 of the PCI DSS.

Source: http://www.focusonpci.com/site/index.php/PCI-101/technical-requirements.html

By separating web and database duties you're limiting your exposure. Typically your db is in a private segment of your network, and inaccessible publicly.

A static VPN connection is also suggested, in PCI, between your web/db and intrusion detection is strongly suggested on your networking equipment. In the event of a compromise the db will be isolated and the VPN connection terminated such that, even though your application and your encryption key are now compromised, access to the data store has been locked down and is inaccessible.

High Availability / Disaster Recovery:

Sander's on point here. Go vote him up. I would add that in the event of even a small maintenance task like taking a filesystem backup or a database dump your db will, at best, be limited to reads-only for some time. In extreme cases I've seen lock wait timeouts and process queues fill up that all available connections are queued or dropped. The site "goes down", effectively.

You can mitigate this by separating your db and scheduling your web server to place the site into maintenance mode during these backup windows without any consequence to the filesystem of the web server.

  • 1
    Security makes this a no-brainer, PCI-DSS or not. As with any sensitive data, there should be a firewall between the front-facing system and the database. – Nic Sep 5 '13 at 17:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.