Quartiz.com is hosted on a Linux server based in Pennsylvania, USA and from time to time, the server needs to be upgraded and rebooted for maintenance. Mostly admins do this during the wee hours, but our company has offices and clients in six different countries across many time zones and we experience downtime during business hours and we cannot afford to have even have a few minutes of downtime. Is there a way to split the DNS settings (I know there can be more than one server names and priority) such a way that if one of the server goes down, another one’s DNS setting is being picked up automatically! To make matters worse, there is an interactive quote form for potential prospects to contact us via Quartiz.com and we store this data in a table on this web server. If we failover to a different server, how could I sync the databases? Has someone resolved such a case successfully? We have our own data centers for running our clients’ applications with redundancy set up, but bringing our own site and prospect response emails to own data center is a security and management issue, without having to separate client sites and ours.
Really really really appreciate a DNS setting based solution (based on server priority) on this one, even if we have to manually sync databases after failover.

Dani AI

Generated

raised two linked problems: keeping the site reachable during planned reboots, and keeping the interactive-quote database in sync when failing over. ’s idea of adding multiple A records and lowering TTL is a common first step, but it is not a complete failover solution.

Multiple A records simply advertise several IPs; there is no built‑in “priority” field for A records (that exists for MX). Recursive resolvers and clients choose and cache addresses in ways that cannot be controlled, and some resolvers ignore very low TTLs or enforce minimum caching. That makes DNS-only failover eventual, not instantaneous. Health checks at the DNS provider help (they can switch records when a server dies), but they still depend on TTL, provider API speed and resolver behavior.

Practical, more reliable approaches:

  • Use a DNS provider with active health checks and automated failover (so the provider updates the A record quickly when the primary fails).
  • Make web servers stateless where possible: move uploads and sessions to shared/object storage or a central session store.
  • Replicate the database: asynchronous master->replica is simple but risks a few seconds of loss; synchronous or clustered solutions (multi-master/Galera-style) reduce loss but add complexity and latency sensitivity.
  • Avoid DNS churn entirely by using a floating IP / VIP (Keepalived/VRRP) or a network/load‑balancer layer (cloud LBs, Anycast, CDN) so failover is handled at routing level and is near instantaneous.

A safe manual failover runbook (high level): verify replica is fully caught up; stop writes on the failed master; promote the replica to master; either switch the VIP or update DNS via API and allow TTL to expire; reconfigure the recovered server as a replica. Critical cautions: prevent split‑brain (only one writable master), log form submissions locally or to a queue as a durability buffer, and rehearse the procedure regularly.

To add to the complexit of domain and site routing, quartiz.com's mail and website requests are separated using and MX and an A record. Mail is hosted on exchange server, whereas website is on a Linux one. I am not sure if this will limit the number of servers where the requests can be routed to. I am not sure how many servers can be listed an A record.

If anyone has knowledge on this info, please post.

Thank you,

commented: Please do not use spammy signatures in your posts, you already have a signature! -3
commented: spammer -3

Hi,

You can specify multiple DNS records but for failover try to setup 2 or more A records may be for example 1st for india and 2nd for US......and specify TTL time like 30 to 60 seconds if one of A record failed to contact then after TTL expires on any then another A record will be called.....

--
Manoj

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.