Message-ID: <514431A6.5000807@catalyst.net.nz>
Date: Sat, 16 Mar 2013 21:47:34 +1300
From: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: Rick Otten <rotten@manta.com>
CC: postgres performance list <pgsql-performance@postgresql.org>
Subject: Re: New server setup
References: <4D6D1410-2208-4DAA-BD64-69BE1FD94E55@autouncle.com>
	<513CADB7.4030803@2ndQuadrant.com>
	<CAJY59_jNGwrPceXg8k04=1VWTTZTFTPTh+jGHopx92c+17Cj1w@mail.gmail.com>
	<20130314185424.GA28770@momjian.us> <51424333.608@catalyst.net.nz>
	<20130314223449.GE28770@momjian.us>
	<7A1B720615F7D9458BE37FA699EF0794044D8C@cmhvm033.ecnext03.local>
In-Reply-To: <7A1B720615F7D9458BE37FA699EF0794044D8C@cmhvm033.ecnext03.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On 16/03/13 07:06, Rick Otten wrote:
>>> I not convinced about the need for BBU with SSD - you *can* use them
>>> without one, just need to make sure about suitable longevity and also
>>> the presence of (proven) power off protection (as discussed
>>> previously). It is worth noting that using unproven or SSD known to be
>>> lacking power off protection with a BBU will *not* save you from
>>> massive corruption (or device failure) upon unexpected power loss.
>
>> I don't think any drive that corrupts on power-off is suitable for a database, but for non-db uses, sure, I guess they are OK, though you have to be pretty money->constrainted to like that tradeoff.
>
> Wouldn't mission critical databases normally be configured in a high availability cluster - presumably with replicas running on different power sources?
>
> If you lose power to a member of the cluster (or even the master), you would have new data coming in and stuff to do long before it could come back online - corrupted disk or not.
>
> I find it hard to imagine configuring something that is too critical to be able to be restored from periodic backup to NOT be in a (synchronous) cluster.  I'm not sure all the fuss over whether an SSD might come back after a hard server failure is really about.  You should architect the solution so you can lose the server and throw it away and never bring it back online again.  Native streaming replication is fairly straightforward to configure.   Asynchronous multimaster (albeit with some synchronization latency) is also fairly easy to configure using third party tools such as SymmetricDS.
>
> Agreed that adding a supercap doesn't sound like a hard thing for a hardware manufacturer to do, but I don't think it should be a necessarily be showstopper for being able to take advantage of some awesome I/O performance opportunities.
>
>

A somewhat extreme point of view. I note that the Mongodb guys added 
journaling for single server reliability a while ago - an admission that 
while in *theory* lots of semi-reliable nodes can be eventually 
consistent, it is a lot less hassle if individual nodes are as reliable 
as possible. That is what this discussion is about.

Regards

Mark


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance