Re: Reliability with RAID 10 SSD and Streaming Replication

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: David Rees <drees76(at)gmail(dot)com>
Cc: Cuong Hoang <climbingrose(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Reliability with RAID 10 SSD and Streaming Replication
Date: 2013-05-17 13:17:52
Message-ID: CAHyXU0y76QkB70kmUk4a7DOfXaN+Gi7NEbWwh-QnhdEy6T-MWQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, May 17, 2013 at 1:34 AM, David Rees <drees76(at)gmail(dot)com> wrote:
> On Thu, May 16, 2013 at 7:46 AM, Cuong Hoang <climbingrose(at)gmail(dot)com> wrote:
>> For our application, a few seconds of data loss is acceptable.
>
> If a few seconds of data loss is acceptable, I would seriously look at
> the synchronous_commit setting and think about turning that off rather
> than risk silent corruption with non-enterprise SSDs.

That is not going to help. Since the drives lie about fsync, upon a
power event you must assume the database is corrupt. I think his
proposed configuration is the best bet (although I would strongly
consider putting SSD on the standby as well). Personally, I think
non SSD drives are obsolete for database purposes and will not
recommend them for any configuration. Ideally though, OP would be
using S3700 and we wouldn't be having this conversation.

merlin

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Merlin Moncure 2013-05-17 13:19:17 Re: Reliability with RAID 10 SSD and Streaming Replication
Previous Message Rob Emery 2013-05-17 11:26:11 Deleting Rows From Large Tables