1

Can an AWS Elastic Load Balancer be setup so it sends all traffic to a main server and if that server fails, only then send traffic to a second server.

Have an existing web app I picked up that was never built to run on multiple servers and the client has become worried about redundancy. They don't want to invest enough to make it run well across multiple servers so I was thinking I could setup a second EC2 server with a MySQL slave and periodically copy files from the primary server to the secondary using rsync. Then have an AWS ELB send traffic to the primary server and only if that fails send it to the second server.

Deej
  • 11
  • 2
  • You can dynamically add EC2 instances to, and remove EC2 instances from, ELB. Alternatively, you could remove ELB from the picture entirely and simply swap a (public) EIP from one host to the other when you need to fail over. – jarmod May 22 '18 at 13:45
  • EIP swap (or) may be use R53 "fail over" approach. When your use case is NOT load balancing between instances, using ELB doesn't make sense. – INVOKE Cloud May 22 '18 at 14:41

1 Answers1

3

AWS load balancers don't support "backup" nodes that only take traffic when the primary is down.

Beyond that, you are proposing a complicated scenario.

was thinking I could setup a second EC2 server with a MySQL slave

If you do that, you can only fail over once, then you can't fail back, because the master database will then be obsolete. For a configuration like this to work and be useful, your two MySQL servers need to be configured with master/master (circular) replication, so that each is a replica of the other. This is an advanced configuration that requires expertise and caution.

For the MySQL component, an RDS instance with multi-AZ enabled will provide you with hands-off fault tolerance of the database.

Of course, the client may be unwilling to pay for this as well.

A reasonable shortcut for small systems might be EC2 instance recovery which will bring the site back up if the underlying hardware fails. This feature replaces a failed instance with a new instance, reattaches the EBS volumes, and starts it back up. If the system is stable and you have a solid backup strategy for all data, this might be sufficient. Effective redundancy as a retrofit is non-trivial.

Michael - sqlbot
  • 169,571
  • 25
  • 353
  • 427
  • I think having a "DB dns" on R53 with fail over setup would be best fit for this case (assuming OP not looking for autos caling and real load balancing act). – INVOKE Cloud May 22 '18 at 14:40
  • 1
    @INVOKECloud the whole thing seems a little delicate. Failing over where the requests arrive is just a tiny part of resiliency, as you know. In my mind, with no exceptions, one should never have the production database share a machine with anything else, but it sounds like here we have a single machine doing everything. That's inherently fragile. – Michael - sqlbot May 22 '18 at 15:11
  • I agree your solution is idle case setup, but OP gets what they pay for. Irrespective whatever way OP choose, they for sure need to address data consistency. – INVOKE Cloud May 22 '18 at 15:23
  • @INVOKECloud exactly. That's what I was referring to when I called the proposed setup "delicate." Data loss or inconsistency could happen very easily. – Michael - sqlbot May 22 '18 at 18:56
  • 2
    "Band-aid" fixes often cost more in the long run and provide less. @Michael-sqlbot suggestion of moving MySQL to RDS is a good low cost improvement with solid benefits. Implementing Master/Slave is not a simple solution to implement and manage yourself (RDS makes this point and click). – John Hanley May 24 '18 at 18:34