Re: Replication and fsync

From: Alban Hertroys <haramrae(at)gmail(dot)com>
To: maillists0(at)gmail(dot)com
Cc: PostgreSQL pg-general List <pgsql-general(at)postgresql(dot)org>
Subject: Re: Replication and fsync
Date: 2013-10-24 21:18:36
Message-ID: D4B12861-984B-4597-9778-373B859261EB@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Oct 24, 2013, at 18:10, maillists0(at)gmail(dot)com wrote:

> Thank you for the answers. I'm still confused. If fsync is not replicated to the slave, then how is replication affected by a corrupt master? If the master dies and there's a commit recorded in the wal log that didn't actually happen, wouldn't the slave still be expected to be in a sane state, with the wal logs accurately reflecting what's on disk?
>
> Maybe I just don't understand streaming replication enough. The docs seem to say that synchronous commits mean that the slave also has to verify a write before a transaction is considered complete. How does fsync affect the way/order in which statements are sent to the slave for replication?

What you're missing is that the master will be replicating corrupt data. That is, _if_ it gets corrupted of course.
But, data corruption in a database has a tendency to go unnoticed for a while.

A corrupted master doesn't necessarily break down immediately - in fact, it can remain running for quite a while as long as the corruption doesn't break stuff in the wrong places or as long as the corrupted records don't get fetched.
Until that time, corruption is just blocks of data on disk, which quite possibly end up being replicated to the slave.

Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll find there is no forest.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Andreas 2013-10-25 01:53:14 Need help how to manage a couple of daily DB copies.
Previous Message Robert James 2013-10-24 21:09:45 Re: Count of records in a row