<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Is Active Active Worth it?</title>
	<atom:link href="http://availabilityadvisor.com/2010/01/20/active-active-worth-it/feed/" rel="self" type="application/rss+xml" />
	<link>http://availabilityadvisor.com/2010/01/20/active-active-worth-it/</link>
	<description>Thoughts on High Availability, Continuous Availability and Fault Tolerance</description>
	<lastBuildDate>Fri, 01 Apr 2011 09:03:00 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Bill Highleyman</title>
		<link>http://availabilityadvisor.com/2010/01/20/active-active-worth-it/#comment-75</link>
		<dc:creator><![CDATA[Bill Highleyman]]></dc:creator>
		<pubDate>Wed, 28 Apr 2010 17:35:56 +0000</pubDate>
		<guid isPermaLink="false">http://availabilityadvisor.com/?p=249#comment-75</guid>
		<description><![CDATA[Andy -

I&#039;m just now getting a little time to catch up on your blog. I read your review of my article with great interest. 

Your points are quite right. However, nothing is perfect. The problem that active/active solves is the failure of a site. If a site fails, and there is no backup, all is lost (the press is full of such stories - check out my Never Again articles in the Availability Digest). Active/active provides two or more geographically-separated sites so that you keep going no matter what. True, there is some data loss if asynchronous replication is used - typically tens to hundreds of milliseconds, but at least you are up-and-running. A solution using just co-located fault-tolerant systems is not disaster tolerant. A site disaster will take down the system. The best you can do is to replicate to a remote site. Assuming that you are using asynchronous replication, you will also lose some data. And recovery could be minutes or hours rather than seconds or subseconds as is being achieved with active/active systems.

By the way, if you use synchronous replication, no data is lost and there is no split-brain mode. You are limited to the disatance between nodes by performance concerns (typically tens of kilometers), but that is better than having all of your eggs in one room.Of course, you&#039;ve got to be pretty clever on how you remove the failed system from the scope of further transactions so that processing can proceed, but there are several solutions to this problem.

Why not add an active/active option to ftServer to make it disaster tolerant and fully faiult tolerant?

- Bill]]></description>
		<content:encoded><![CDATA[<p>Andy -</p>
<p>I&#8217;m just now getting a little time to catch up on your blog. I read your review of my article with great interest. </p>
<p>Your points are quite right. However, nothing is perfect. The problem that active/active solves is the failure of a site. If a site fails, and there is no backup, all is lost (the press is full of such stories &#8211; check out my Never Again articles in the Availability Digest). Active/active provides two or more geographically-separated sites so that you keep going no matter what. True, there is some data loss if asynchronous replication is used &#8211; typically tens to hundreds of milliseconds, but at least you are up-and-running. A solution using just co-located fault-tolerant systems is not disaster tolerant. A site disaster will take down the system. The best you can do is to replicate to a remote site. Assuming that you are using asynchronous replication, you will also lose some data. And recovery could be minutes or hours rather than seconds or subseconds as is being achieved with active/active systems.</p>
<p>By the way, if you use synchronous replication, no data is lost and there is no split-brain mode. You are limited to the disatance between nodes by performance concerns (typically tens of kilometers), but that is better than having all of your eggs in one room.Of course, you&#8217;ve got to be pretty clever on how you remove the failed system from the scope of further transactions so that processing can proceed, but there are several solutions to this problem.</p>
<p>Why not add an active/active option to ftServer to make it disaster tolerant and fully faiult tolerant?</p>
<p>- Bill</p>
]]></content:encoded>
	</item>
</channel>
</rss>

