EC2 database server failover strategy

Question

I am planning to deploy my web app to EC2. I have several webserver instances. I have 1 primary database instance. I have 1 failover database instance. I need a strategy to redirect the webservers to the failover database instance IP when the primary database instance fails.

I was hoping I could use an Elastic IP in my connection strings. But, the webservers are not able to access/ping the Elastic IP. I have several brute force ideas to solve the problem. However, I am trying to find the most elegant solution possible.

I am using all .Net and SQL Server. My connection strings are encrypted.

Does anybody have a strategy for failing over a database instance in EC2 using some form of automation or DNS configuration?

Please let me know.

Answer 1

http://alestic.com/2009/06/ec2-elastic-ip-internal

tells you how to use the Elastic IP public DNS.

Answer 2

Haven't used EC2 but surely you need to either:

(a) put your front-end into some custom maintenance mode, that you define, while you switch the IP over; and have the front-end perform required steps to manage potential data integrity and data loss issues related to the previous server going down and the new server coming up when it enters and leaves your custom maintenance mode

OR, for a zero down-time system:

(b) design the system at the object/relational and transaction levels from the ground up to support zero-down-time fail-over. It's not something you can bolt on quicjkly to just any application.

(c) use some database support for automatic failover. I am unaware whether SQL Server support for failover suitable for your application exists or is appropriate here. I suggest adding a "sql-server" tag to the question to start a search for the right audience.

If Elastic IPs don't work (which sounds odd to say the least - shouldn't you talk to EC2 about that), you mayhave to be able to instruct your front-end which new database IP to use at the same time as telling it to go from maintenance mode to normal mode.

Answer 3

If you're willing to shell out a bit of extra money, take a look at Rightscale's tools; they've built custom server images and supporting tools that handle database failover (among many other things). This link explains how to do it with MySQL, so will hopefully show you some principles even though it doesn't use SQL Server.

Answer 4

I always thought there was this possibility in the connnection string

This is taken (but not yet tested) from How to add Failover Partner to a connection string in VB.NET :

If you connect with ADO.NET or the SQL Native Client to a database that is being mirrored, your application can take advantage of the drivers ability to automatically redirect connections when a database mirroring failover occurs. You must specify the initial principal server and database in the connection string and the failover partner server.

Data Source=myServerAddress;Failover Partner=myMirrorServerAddress;
Initial Catalog=myDataBase;Integrated Security=True;

There is ofcourse many other ways to write the connection string using database mirroring, this is just one example pointing out the failover functionality. You can combine this with the other connection strings options available.

Answer 5

To broaden gareth's answer, cloud management softwares usually solve this type of problems. RightScale is one of them, but you can try enStratus or Scalr (disclaimer: I work at Scalr). These tools provide failover solutions like:

• Backups: you can schedule automated snapshots of the EBS volume containing the data
• Fault-tolerant database: in the event of failure, a slave is promoted master and mounted storage will be switched if the failed master and new master are in the same AZ, or a snapshot taken of the volume

If you want to build your own solution, you could replicate the process detailed below that we use at Scalr:

• Is there a slave in the same AZ? If so, promote it, switch EBS volumes (which are limited to a single AZ), switch any ElasticIP you might have, reconfigure replication of the remaining slaves.
• If not, is there a slave fully replicated in another AZ? If so, promote it, then do the above.
• If there are no slave in same AZ, and no slave fully replicated in another AZ, then create a snapshot from master's volume, and use this snapshot to create a new volume in an AZ where a slave is running. Then do the above.