Re: Risk of data corruption/loss? - Mailing list pgsql-performance

From Niels Kristian Schjødt
Subject Re: Risk of data corruption/loss?
Date
Msg-id 7363B175-051D-4F2B-8D37-0678016BFD21@autouncle.com
Whole thread Raw
In response to Re: Risk of data corruption/loss?  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-performance

Den 13/03/2013 kl. 18.13 skrev Jeff Janes <jeff.janes@gmail.com>:

On Wed, Mar 13, 2013 at 8:24 AM, Niels Kristian Schjødt <nielskristian@autouncle.com> wrote:
I'm considering the following setup:

- Master server with battery back raid controller with 4 SAS disks in a RAID 0 - so NO mirroring here, due to max performance requirements.
- Slave server setup with streaming replication on 4 HDD's in RAID 10. The setup will be done with synchronous_commit=off and synchronous_standby_names = ''

Out of curiosity, in the presence of BB controller, is synchronous_commit=off getting you additional performance?

Time will show :-)


So as you might have noticed, clearly there is a risk of data loss, which is acceptable, since our data is not very crucial. However, I have quite a hard time figuring out, if there is a risk of total data corruption across both server in this setup? E.g. something goes wrong on the master and the wal files gets corrupt. Will the slave then apply the wal files INCLUDING the corruption (e.g. an unfinished transaction etc.), or will it automatically stop restoring at the point just BEFORE the corruption, so my only loss is data AFTER the corruption?

It depends on where the corruption happens.  WAL is checksummed, so the slave will detect a mismatch and stop applying records.  However, if the corruption happens in RAM before the checksum is taken, the checksum will match and it will attempt to apply the records.

Cheers,

Jeff

pgsql-performance by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Risk of data corruption/loss?
Next
From: Niels Kristian Schjødt
Date:
Subject: Setup of four 15k SAS disk with LSI raid controller