3 ms·

We have a backup set of servers at a different data center as well. But routing traffic via DNS change to different data center isn't the best approach as some

We have a backup set of servers at a different data center as well. But routing traffic via DNS change to different data center isn't the best approach as some ISPs cache DNS and would still send traffic to old data center. A solution to this would be to have a round robin DNS to different data centers but that is still plagued if one data center develops a network issue. The only real solution to this is BGP routing which is complicated to setup and VERY expensive (only big guys do it). Here's some excellent answers on SO: http://serverfault.com/questions/153576/global-high-availability-setup-question http://serverfault.com/questions/153576/global-high-availabi...

cbf 15y ago
But routing traffic via DNS change to different data center isn't the best approach as some ISPs cache DNS and would still send traffic to old data center. All resolvers cache records for the TTL (or SOA minimum for negative lookups) specified by your authoritative servers. A solution to this would be to have a round robin DNS to different data centers but that is still plagued if one data center develops a network issue. If the clients are web browsers they will try the alternative addresses in a record set if the one they pick doesn't respond.
AgentConundrum 15y ago
Forgive my ignorance, but isn't it normal to cache the DNS for 24 hours or so by default? I think it's typical (though I've never done it, so I'll apologize again if I'm talking out of my ass here) to drop the TTL down to basically nothing well ahead of the migration so that when you flip the switch, everyone will notice almost immediately, and then you can push the TTL back up to normal on the updated record.