Re: Reliability with RAID 10 SSD and Streaming Replication

From: David Rees <drees76(at)gmail(dot)com>
To: Cuong Hoang <climbingrose(at)gmail(dot)com>
Cc: "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 06:34:15
Message-ID: CAHtT9Rv+mtTC=Ani+-VcnKDNE+We5hTb4BVHf8R+HPc=wAiE-g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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.

http://www.postgresql.org/docs/9.2/interactive/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT

"Unlike fsync, setting this parameter to off does not create any risk
of database inconsistency: an operating system or database crash might
result in some recent allegedly-committed transactions being lost, but
the database state will be just the same as if those transactions had
been aborted cleanly. So, turning synchronous_commit off can be a
useful alternative when performance is more important than exact
certainty about the durability of a transaction."

With a default wal_writer_delay setting of 200ms, you will only be at
risk of losing at most 600ms of transactions in the event of an
unexpected crash or power loss, but write performance should go up a
huge amount, especially if they are a lot of small writes as you
describe.

-Dave

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Rob Emery 2013-05-17 11:26:11 Deleting Rows From Large Tables
Previous Message Mark Kirkwood 2013-05-17 01:34:40 Re: Reliability with RAID 10 SSD and Streaming Replication