Comments on: High-Performance DNS for The Cloud http://www.igvita.com/2008/09/22/high-performance-dns-for-the-cloud/ A goal is a dream with a deadline. Sun, 05 Jul 2009 04:09:45 +0000 http://wordpress.org/?v=2.7.1 hourly 1 By: Ilya Grigorik http://www.igvita.com/2008/09/22/high-performance-dns-for-the-cloud/comment-page-1/#comment-134235 Ilya Grigorik Tue, 23 Sep 2008 12:26:33 +0000 http://www.igvita.com/?p=193#comment-134235 Ah, that's a good one. If we need to keep databases in sync, we'll take the most recent snapshot, bring it up and set it up as a slave of the current production database. Then, when we flip the switch on DNS, we reverse the relationship between the databases. That way, we can still do a live rollback. Of course, if part of the upgrade are database schemas, then it gets a bit more complicated. Ah, that’s a good one. If we need to keep databases in sync, we’ll take the most recent snapshot, bring it up and set it up as a slave of the current production database. Then, when we flip the switch on DNS, we reverse the relationship between the databases. That way, we can still do a live rollback.

Of course, if part of the upgrade are database schemas, then it gets a bit more complicated.

]]> By: Mean Business » Blog Archive » links for 2008-09-23 http://www.igvita.com/2008/09/22/high-performance-dns-for-the-cloud/comment-page-1/#comment-134200 Mean Business » Blog Archive » links for 2008-09-23 Tue, 23 Sep 2008 09:00:41 +0000 http://www.igvita.com/?p=193#comment-134200 [...] High-Performance DNS for The Cloud - igvita.com (tags: AWS cloud deployment architecture) [...] [...] High-Performance DNS for The Cloud - igvita.com (tags: AWS cloud deployment architecture) [...]

]]> By: W. Andrew Loe III http://www.igvita.com/2008/09/22/high-performance-dns-for-the-cloud/comment-page-1/#comment-134009 W. Andrew Loe III Mon, 22 Sep 2008 16:47:10 +0000 http://www.igvita.com/?p=193#comment-134009 How do you deal with database drift during the transition? Do you just point your new infrastructure at your production database and migrate it, designing so that your changes are backwards compatible? How do you deal with database drift during the transition? Do you just point your new infrastructure at your production database and migrate it, designing so that your changes are backwards compatible?

]]>