5

I run two completely independent websites. I am moving their MySQL databases to Amazon RDS.

I'm not going to do Multi A/Z deployment - let's remove that variable from this question.

I'm not sure whether to create a single RDS instance with two databases, or two Amazon RDS instances with a single database. Ignore cost for the sake of this question. I will not hit the 1 TB data limit so let's ignore that. However, it is extremely important that crashing one of the websites doesn't impact the other.

Based on this document - http://docs.amazonwebservices.com/AmazonRDS/latest/UserGuide/Concepts.DBInstance.html

I'm assuming that if I write terrible code that crashes one of the databases in a given RDS instance, it could possibly take down the entire RDS instance (and thus inadvertantly affect the other database). Is that correct?

In response to the comment, we're definitely entertaining the idea of two RDS instances, each with its own database. I just want to make sure that there is actually a benefit to doing that - I'm assuming the benefit is that these databases won't possibly affect each other when they're on separate instances. I thought there was a shot that even on the same instance, they couldn't impact each other, but it sounds like that's not the case.

--EDIT Hop3less - thanks for the answer - however, When I said a two RDS instances with a single database, i meant each having a single database. Just want to make sure you realize I don't mean two EC2 instances. I assume a single RDS instance is still a single point of failure?

2
  • And we're not entertaining the idea of two RDS instances, each with its own database, because...? Sep 5, 2012 at 3:40
  • Yes, a single instance is still a single point of failure. Any number of ways to bring down the OS, in which case, both databases will be inaccessible as well. Sep 6, 2012 at 20:35

4 Answers 4

1

Right, if you have two instances with one database, your single-point-of-failure is the single database - anything that impacts on the database (like too much load, or accidentally deleting it, or what have you) will impact on both sites that use it.

If you have one instance with two databases, then your single-point-of-failure is the instance, and anything that impacts on the instance (such as running your OS out of disk space, for example) will impact on both sites that use it.

The only setup that allows for your sites to be completely independent of each other is to run each one on its own instance, with its own database. (And even that's not "completely" independent, just as completely independent as you can control - if something happens to hardware or infrastructure the two instances share, they'd both be impacted.)

1

I agree with @HopelessN00b’s suggestion that in order for each of your sites to be completely independent, you should run each DB on its own instance. Yet, even that isn’t a completely independent setup, but using database(s) in the cloud can minimize certain risks. Since you are concerned with high availability of your DBs and you’re planning to move them to RDS, I thought to suggest you look into Xeround’s cloud DB option as an alternative to RDS. If I understand properly Xeround offers a DB that’s distributed over multiple servers and has replication as well, both are features that can deal with failover (here’s some wiki info about distributed systems and replication. :)

0

CPU and memory will be the single point of contention, never mind the IO profiles for each application. If one application suddenly becomes more popular than the other, the buffer pool's LRU algorithm will being paging out row and index data from one application in favor of the other, resulting in performance degradation for the paged application as its reads must go to disk.

mysql> SHOW ENGINE INNODB STATUS;

Is going to provide buffer pool metrics for your app to monitor if this type of contention is occurring. (http://dev.mysql.com/doc/refman/5.5/en/innodb-buffer-pool.html)

From a DR perspective, any snapshot or PITR restore will bring both applications down and force a rollback for both apps. With separate instances, you don't have that dependency.

0

So... Single RDS with multiple databases/schemas:

  • Likely Cheaper
  • Easier to manage (single root credential)
  • Need to ensure multi-AZ to avoid maintenance downtime
  • Single snapshot has all databases included
  • Roll back of one means rollback of all
  • Less likely to hit default number of RDS per account limit
  • Failure of this RDS instance means downtime or required failover to secondary for all databases

Single RDS with single database/schema

  • More costly. Remember that each RDS has minimum storage size.
  • Harder to manage
    • multiple root credentials
    • Need to juggle potentially disparate configurations
  • Maintenance downtime of one RDS does not impact any other
  • Rollback of one does not affect any of the other databases, although now more costly due to multiple snapshots
  • Faster snapshots/repliacation?
  • Failure of this RDS instance does not affect any other databases

I think this really depends on the scenario. If you have multiple databases that are dependent on each other then it makes sense (especially cost-wise) to put it into a single RDS. If outage of one database corrupts the entire process anyways then they may as well reside in the same RDS. However, if you have two databases that have no relationship to each other such as employee information and customer orders (assuming no commission here) then failure of one shouldn't affect the other and they probably should reside in the different RDS. Same goes if two databases are managed by separate teams or a single team. It would probably make more sense not to have two teams share a single RDS instance.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .