<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Weekly Release Blog #11 &#8211; Zero-Downtime Database Deployment</title>
	<atom:link href="http://exortech.com/blog/2009/02/01/weekly-release-blog-11-zero-downtime-database-deployment/feed/" rel="self" type="application/rss+xml" />
	<link>http://exortech.com/blog/2009/02/01/weekly-release-blog-11-zero-downtime-database-deployment/</link>
	<description>Peripatetic thinking</description>
	<lastBuildDate>Sat, 15 Jan 2011 18:20:06 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Benjamin Starks</title>
		<link>http://exortech.com/blog/2009/02/01/weekly-release-blog-11-zero-downtime-database-deployment/comment-page-1/#comment-559</link>
		<dc:creator>Benjamin Starks</dc:creator>
		<pubDate>Tue, 09 Nov 2010 18:39:06 +0000</pubDate>
		<guid isPermaLink="false">http://exortech.com/blog/?p=102#comment-559</guid>
		<description>Mutating a schema change is the major problem we are also facing. With 20+ web-server frontends all hitting the database we can&#039;t just bring all of them down to change the logic structure.

We looked at Liquibase for a while, but even though it builds automatically scripts that can apply a schema change, the time it takes to do it for our 8GB+ db locks up the application. We are giving ChronicDB a go next.</description>
		<content:encoded><![CDATA[<p>Mutating a schema change is the major problem we are also facing. With 20+ web-server frontends all hitting the database we can&#8217;t just bring all of them down to change the logic structure.</p>
<p>We looked at Liquibase for a while, but even though it builds automatically scripts that can apply a schema change, the time it takes to do it for our 8GB+ db locks up the application. We are giving ChronicDB a go next.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pawan</title>
		<link>http://exortech.com/blog/2009/02/01/weekly-release-blog-11-zero-downtime-database-deployment/comment-page-1/#comment-545</link>
		<dc:creator>Pawan</dc:creator>
		<pubDate>Fri, 01 Oct 2010 12:28:02 +0000</pubDate>
		<guid isPermaLink="false">http://exortech.com/blog/?p=102#comment-545</guid>
		<description>if stage servers DB servers are there stop data flow from stage to Primary DB servers, you can take one more mirror server, do deployment on it and do testing, once successfull, failover the server and make principal down, and start data flow from stage to Primary server. This will not affect existing users. Hope it would help</description>
		<content:encoded><![CDATA[<p>if stage servers DB servers are there stop data flow from stage to Primary DB servers, you can take one more mirror server, do deployment on it and do testing, once successfull, failover the server and make principal down, and start data flow from stage to Primary server. This will not affect existing users. Hope it would help</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris</title>
		<link>http://exortech.com/blog/2009/02/01/weekly-release-blog-11-zero-downtime-database-deployment/comment-page-1/#comment-510</link>
		<dc:creator>Chris</dc:creator>
		<pubDate>Sun, 21 Feb 2010 00:16:00 +0000</pubDate>
		<guid isPermaLink="false">http://exortech.com/blog/?p=102#comment-510</guid>
		<description>You may want to have a look at a product called ChronicDB. It offers zero-downtime database deployment in a way that solves the chicken-or-the-egg problem.</description>
		<content:encoded><![CDATA[<p>You may want to have a look at a product called ChronicDB. It offers zero-downtime database deployment in a way that solves the chicken-or-the-egg problem.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Simon Harris</title>
		<link>http://exortech.com/blog/2009/02/01/weekly-release-blog-11-zero-downtime-database-deployment/comment-page-1/#comment-509</link>
		<dc:creator>Simon Harris</dc:creator>
		<pubDate>Wed, 20 Jan 2010 04:19:09 +0000</pubDate>
		<guid isPermaLink="false">http://exortech.com/blog/?p=102#comment-509</guid>
		<description>How do you handle views (if at all)?

Have you had to handle column type changes?</description>
		<content:encoded><![CDATA[<p>How do you handle views (if at all)?</p>
<p>Have you had to handle column type changes?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Rich</title>
		<link>http://exortech.com/blog/2009/02/01/weekly-release-blog-11-zero-downtime-database-deployment/comment-page-1/#comment-508</link>
		<dc:creator>Scott Rich</dc:creator>
		<pubDate>Fri, 15 Jan 2010 17:48:23 +0000</pubDate>
		<guid isPermaLink="false">http://exortech.com/blog/?p=102#comment-508</guid>
		<description>Great article, thanks.  I hope this isn&#039;t a naive question, but this scheme doesn&#039;t seem to allow for any form of &quot;mutating&quot; schema change, changing the logical or physical type of a column, for example.  Is the assumption that this has to be done by moving the new app version to a new column and deprecating the old?</description>
		<content:encoded><![CDATA[<p>Great article, thanks.  I hope this isn&#8217;t a naive question, but this scheme doesn&#8217;t seem to allow for any form of &#8220;mutating&#8221; schema change, changing the logical or physical type of a column, for example.  Is the assumption that this has to be done by moving the new app version to a new column and deprecating the old?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Zero Downtime Continuous Deployment &#171; Lean Builds</title>
		<link>http://exortech.com/blog/2009/02/01/weekly-release-blog-11-zero-downtime-database-deployment/comment-page-1/#comment-489</link>
		<dc:creator>Zero Downtime Continuous Deployment &#171; Lean Builds</dc:creator>
		<pubDate>Tue, 01 Dec 2009 00:04:31 +0000</pubDate>
		<guid isPermaLink="false">http://exortech.com/blog/?p=102#comment-489</guid>
		<description>[...] since you&#8217;ve potentially got lots of dependency problems; luckily, the Exortech blog recently addressed this issue as [...]</description>
		<content:encoded><![CDATA[<p>[...] since you&#8217;ve potentially got lots of dependency problems; luckily, the Exortech blog recently addressed this issue as [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: exortech.com &#187; Blog Archive &#187; Back from Bangalore (and Hyderabad and Mumbai)</title>
		<link>http://exortech.com/blog/2009/02/01/weekly-release-blog-11-zero-downtime-database-deployment/comment-page-1/#comment-458</link>
		<dc:creator>exortech.com &#187; Blog Archive &#187; Back from Bangalore (and Hyderabad and Mumbai)</dc:creator>
		<pubDate>Thu, 17 Sep 2009 05:56:43 +0000</pubDate>
		<guid isPermaLink="false">http://exortech.com/blog/?p=102#comment-458</guid>
		<description>[...] presentation also stimulated some good side chatter on twitter. In general, zero-downtime database deployment, continuous monitoring and WAGMI seemed to be popular topics. Thanks to everyone who made it out [...]</description>
		<content:encoded><![CDATA[<p>[...] presentation also stimulated some good side chatter on twitter. In general, zero-downtime database deployment, continuous monitoring and WAGMI seemed to be popular topics. Thanks to everyone who made it out [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: exortech.com &#187; Blog Archive &#187; Speaking at DevTeach Vancouver</title>
		<link>http://exortech.com/blog/2009/02/01/weekly-release-blog-11-zero-downtime-database-deployment/comment-page-1/#comment-354</link>
		<dc:creator>exortech.com &#187; Blog Archive &#187; Speaking at DevTeach Vancouver</dc:creator>
		<pubDate>Fri, 19 Jun 2009 14:44:24 +0000</pubDate>
		<guid isPermaLink="false">http://exortech.com/blog/?p=102#comment-354</guid>
		<description>[...] Zero down-time deployment [...]</description>
		<content:encoded><![CDATA[<p>[...] Zero down-time deployment [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: exortech</title>
		<link>http://exortech.com/blog/2009/02/01/weekly-release-blog-11-zero-downtime-database-deployment/comment-page-1/#comment-238</link>
		<dc:creator>exortech</dc:creator>
		<pubDate>Wed, 01 Apr 2009 05:44:08 +0000</pubDate>
		<guid isPermaLink="false">http://exortech.com/blog/?p=102#comment-238</guid>
		<description>Thanks for the feedback, Saem. I haven&#039;t tried out LiquiBase, but it looks interesting (btw, Hawk also contacted me with this recommendation). I can see the value of changesets over versioning individual migrations. Does LiquiBase support a script language for building migrations - instead of having to use xml?</description>
		<content:encoded><![CDATA[<p>Thanks for the feedback, Saem. I haven&#8217;t tried out LiquiBase, but it looks interesting (btw, Hawk also contacted me with this recommendation). I can see the value of changesets over versioning individual migrations. Does LiquiBase support a script language for building migrations &#8211; instead of having to use xml?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: saem</title>
		<link>http://exortech.com/blog/2009/02/01/weekly-release-blog-11-zero-downtime-database-deployment/comment-page-1/#comment-237</link>
		<dc:creator>saem</dc:creator>
		<pubDate>Tue, 31 Mar 2009 23:43:01 +0000</pubDate>
		<guid isPermaLink="false">http://exortech.com/blog/?p=102#comment-237</guid>
		<description>You might want to give liquibase a shot. It has the ability to generate sql if desired, and unlike migrations which are up/down, it&#039;s based on changesets.</description>
		<content:encoded><![CDATA[<p>You might want to give liquibase a shot. It has the ability to generate sql if desired, and unlike migrations which are up/down, it&#8217;s based on changesets.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

