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
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 |