Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Ud8CM-0001ET-SY for pgsql-performance@arkaria.postgresql.org; Fri, 17 May 2013 00:07:03 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1Ud8CM-0000NA-9N for pgsql-performance@arkaria.postgresql.org; Fri, 17 May 2013 00:07:02 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Ud8CK-0000Li-8y for pgsql-performance@postgresql.org; Fri, 17 May 2013 00:07:00 +0000 Received: from mail.gransy.com ([2001:1528:137::f1]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Ud8CD-000583-Mo for pgsql-performance@postgresql.org; Fri, 17 May 2013 00:06:59 +0000 Received: from antispam.gransy.com (antispam.gransy.com [77.78.104.124]) by mail.gransy.com (Postfix) with ESMTP id 08398508AAE for ; Fri, 17 May 2013 02:06:50 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at antispam.gransy.com X-Spam-Flag: NO X-Spam-Score: 0.407 X-Spam-Level: X-Spam-Status: No, score=0.407 tagged_above=0 required=5 tests=[ALL_TRUSTED=-1, AWL=-0.292, BAYES_00=-1.9, FS_REPLICA=3.599] 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 P6UWQf7puK1B for ; Fri, 17 May 2013 02:06:48 +0200 (CEST) Received: by mail.gransy.com (Postfix, from userid 5000) id B4F53508ADB; Fri, 17 May 2013 02:06:49 +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 86AC6508AAE for ; Fri, 17 May 2013 02:06:49 +0200 (CEST) Message-ID: <51957499.6050905@fuzzy.cz> Date: Fri, 17 May 2013 02:06:49 +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: In-Reply-To: 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 Hi, On 16.5.2013 16:46, Cuong Hoang wrote: > Hi all, > > Our application is heavy write and IO utilisation has been the problem > for us for a while. We've decided to use RAID 10 of 4x500GB Samsung 840 What does "heavy write" mean in your case? Does that mean a lot of small transactions or few large ones? What have you done to tune the server? > Pro for the master server. I'm aware of write cache issue on SSDs in > case of power loss. However, our hosting provider doesn't offer any > other choices of SSD drives with supercapacitor. To minimise risk, we > will also set up another RAID 10 SAS in streaming replication mode. For > our application, a few seconds of data loss is acceptable. Streaming replication allows zero data loss if used in synchronous mode. > My question is, would corrupted data files on the primary server affect > the streaming standby? In other word, is this setup acceptable in terms > of minimising deficiency of SSDs? It should be. 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. Tomas -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance