Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UeX9m-0001zi-Uw for pgsql-performance@arkaria.postgresql.org; Mon, 20 May 2013 20:58:11 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1UeX9m-000282-7k for pgsql-performance@arkaria.postgresql.org; Mon, 20 May 2013 20:58:10 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UeX9l-00027w-3j for pgsql-performance@postgresql.org; Mon, 20 May 2013 20:58:09 +0000 Received: from mail.gransy.com ([2001:1528:137::f1]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UeX9i-00005Y-7h for pgsql-performance@postgresql.org; Mon, 20 May 2013 20:58:08 +0000 Received: from antispam.gransy.com (antispam.gransy.com [77.78.104.124]) by mail.gransy.com (Postfix) with ESMTP id B1AB5508B71 for ; Mon, 20 May 2013 22:58:03 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at antispam.gransy.com X-Spam-Flag: NO X-Spam-Score: 2.055 X-Spam-Level: ** X-Spam-Status: No, score=2.055 tagged_above=0 required=5 tests=[ALL_TRUSTED=-1, AWL=-0.456, BAYES_00=-1.9, FS_REPLICA=3.599, SARE_SPEC_REPLICA_OBFU=1.812] autolearn=no Received: from mail.gransy.com ([82.208.44.189]) by antispam.gransy.com (antispam.gransy.com [77.78.104.124]) (amavisd-new, port 10024) with ESMTP id VAOD61ClMIkd for ; Mon, 20 May 2013 22:57:53 +0200 (CEST) Received: by mail.gransy.com (Postfix, from userid 5000) id 61590508B5A; Mon, 20 May 2013 22:58:03 +0200 (CEST) Received: from [192.168.1.237] (ip-78-45-139-138.net.upcbroadband.cz [78.45.139.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.gransy.com (Postfix) with ESMTPSA id 9E932508B5A for ; Mon, 20 May 2013 22:57:13 +0200 (CEST) Message-ID: <519A8E29.60702@fuzzy.cz> Date: Mon, 20 May 2013 22:57:13 +0200 From: Tomas Vondra User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Reliability with RAID 10 SSD and Streaming Replication References: <51957499.6050905@fuzzy.cz> <519991EB.8010208@2ndQuadrant.com> In-Reply-To: <519991EB.8010208@2ndQuadrant.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: 0.8 (/) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On 20.5.2013 05:00, Greg Smith wrote: > On 5/16/13 8:06 PM, Tomas Vondra wrote: >> Have you considered using a UPS? That would make the SSDs about as >> reliable as SATA/SAS drives - the UPS may fail, but so may a BBU unit on >> the SAS controller. > > That's not true at all. Any decent RAID controller will have an option > to stop write-back caching when the battery is bad. Things will slow > badly when that happens, but there is zero data risk from a short-term > BBU failure. The only serious risk with a good BBU setup are that > you'll have a power failure lasting so long that the battery runs down > before the cache can be flushed to disk. That's true, no doubt about that. What I was trying to say is that a controller with BBU (or a SSD with proper write cache protection) is about as safe as an UPS when it comes to power outages. Assuming both are properly configured / watched / checked. Sure, there are scenarios where UPS is not going to help (e.g. a PSU failure) so a controller with BBU is better from this point of view. I've seen crashes with both options (BBU / UPS), both because of misconfiguration and hw issues. BTW I don't know what controller are we talking about here - it might be as crappy as the SSD drives. What I was thinking about in this case is using two SSD-based systems with UPSes. That'd allow fast failover (which may not be possible with the SAS based replica, as it does not handle the load). But yes, I do agree that the provider should be ashamed for not providing reliable SSDs in the first place. Getting reliable SSDs should be the first option - all these suggestions are really just workarounds of this rather simple issue. Tomas -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance