Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UGZmb-0003vZ-9k for pgsql-performance@arkaria.postgresql.org; Fri, 15 Mar 2013 18:55:13 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1UGZma-0000Gq-P4 for pgsql-performance@arkaria.postgresql.org; Fri, 15 Mar 2013 18:55:12 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UGZmZ-0000Fv-K6 for pgsql-performance@postgresql.org; Fri, 15 Mar 2013 18:55:11 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UGZmX-0005gD-80 for pgsql-performance@postgresql.org; Fri, 15 Mar 2013 18:55:10 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1UGZmW-0004ox-80; Fri, 15 Mar 2013 14:55:08 -0400 Date: Fri, 15 Mar 2013 14:55:08 -0400 From: Bruce Momjian To: Rick Otten Cc: postgres performance list Subject: Re: New server setup Message-ID: <20130315185508.GA17688@momjian.us> References: <4D6D1410-2208-4DAA-BD64-69BE1FD94E55@autouncle.com> <513CADB7.4030803@2ndQuadrant.com> <20130314185424.GA28770@momjian.us> <51424333.608@catalyst.net.nz> <20130314223449.GE28770@momjian.us> <7A1B720615F7D9458BE37FA699EF0794044D8C@cmhvm033.ecnext03.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7A1B720615F7D9458BE37FA699EF0794044D8C@cmhvm033.ecnext03.local> User-Agent: Mutt/1.5.20 (2009-06-14) X-Pg-Spam-Score: -4.3 (----) 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 Fri, Mar 15, 2013 at 06:06:02PM +0000, Rick Otten wrote: > >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. Do you want to recreate the server if it loses power over an extra $100 per drive? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance