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 <bruce@xxxxxxxxxx> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
