Inform browsers that they should refresh their DNS cache?

The problem with your question is the flawed assumption that the client browsers have anything to do with DNS resolution. In almost all cases, they don't. They let the underlying OS's DNS resolver handle name resolution and caching mechanics.

If your failover strategy is tied to a DNS record change, your only option for a quicker client turnaround is to lower the TTL value on the record in question. The TTL is what determines how long a client caches the result of that record lookup. Note: It's also possible to lower the TTL on an entire DNS zone. But that's not likely what you want or need here.

Migrating to a more traditional load balancer works around your problem by putting a virtual/floating IP address in front of the real server's IP so you don't have to make any DNS changes and your failovers can be more or less instantaneous.

I don't believe asking people to flush their DNS cache is practical. Most average people don't know what DNS is, don't know what a cache is, and wouldn't be able to flush their DNS cache even if you provided phone based technical support. Think about having to flush a DNS cache in a router - there are hundreds of models of routers. If your customers are all highly technical, maybe it's a bit more practical, but consumers, no.

I think you need a technical solution you can control.

You're probably best using a DNS service designed for this, like AWS Route 53. R53 can be used with any servers, anywhere, not just AWS servers / services. R53 can work somewhat like a load balancer, there are multiple routing types - failover, weighted, latency, etc. You could use failover routing so it automatically routes to the backup server if the primary goes down.

Another option, which I'm fairly sure won't work, is using multiple A records. The question here is which record will browsers use? From what I've read my impression is browsers should use the A records randomly, but they don't, they use the first one - though I don't know how "first" is defined. Services that distribute load using DNS tend to randomise the order of the IP addresses returned.

Another option, mentioned in the comments, is a reverse proxy. I didn't include this originally because it would mean more hardware. If you put a reverse proxy or load balancer in front of the server/service it can redirect traffic to wherever it needs to go. My suggestion above of using Route53 would perform a similar function, not quite as well, but probably a little better than standard DNS.

A 302 temporary redirect could potentially be used, but you'd need a server that can consistently send those redirects while the main server is down. That would require additional hardware, though not very much hardware.

Is there a way for Apache HTTPD (some kind of HTTP header) to tell users' browsers that they should flush their DNS cache.

No such mechanism exists, all modern web browsers and the code they execute run a in sandbox from which they shouldn't be able to change OS settings.

Local DNS cache isn't managed by users' browsers. It's managed at the OS level. Changing the local DNS cache is an administrator activity. For security reasons, browsers are not designed to execute administrative functions on their host machine.

What you need is a server-side solution. A common solution for this type of problem is to use a reverse proxy such as nginx, or apache.

To do that in a way that allows both your main and backup servers to have downtime, you can run the reverse proxy in a virtual machine that has one or more dedicated IP addresses. That way you (or your cloud provider) only has to maintain the VM; the hardware supporting it can fluctuate.

Your setup would then be:

• Public-facing VM: www.yourdomain.com
• Backend main server: <ip address for main>
• Backend backup server: <ip address for backup>
• DNS for your website points to the VM www.yourdomain.com

If you use nginx, public websites to be proxied are stored as file definitions in the sites-available directory and activated by sym-linking them to the sites-enabled directory. You could either have one site definition per backend server and switch them by changing the symlink or you could have one site definition with a proxy_pass directive for each backend machine, but with one of those directives commented out.

Whichever way you set that up, to switch backends all you have to do is change the site file, then tell nginx to reload its config: service nginx reload.

Here's an example site file with a proxy_pass directive for each backend and one of them commented out:

server {
    listen       80;
    listen       [::]:80;
    server_name  yourdomain.com www.yourdomain.com;

    location / {
            proxy_pass         http://<ip address of main>:80;
            # proxy_pass         http://<ip address of backup>:80;
            proxy_redirect     off;

            proxy_set_header   Host             $host;
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    }
}

You can do much more than this, including caching static content on the reverse proxy, but this much should get you started.