Re: Clarifying File System Syncs

Elein,

> I know how to do this safely with the db down.
> I'm talking about the points of failure for
> a live system.
>
> I'm arguing for the erserver and need some fodder
> against file system "syncing". Also, I want
> confirmation and someone else's words that the points
> of failure are the cache and intertwined transactions and
> incomplete transactions.

As far as I know, that's the entirety of the problem. Neither transaction
flushing nor sync operations is instantaneous; in a busy database, attempts
to, for example, rsync the database files is more likely to result in partial
or duplicate transactions than not. The situation with the WAL files
themselves is even worse; attempts to sync these files in /xlog would almost
certainly result in errors.

I can give a detailed explanation if it's needed as a 2nd-party opinion.

The cache should actually not be a problem with sync-ing. The shared buffer
cache is just for pending transactions, and its contents therefore do not
need to be sync-ed, and in theory the kernel cache should notice the request
for in-memory data from the sync utility and supply the up-to-date files from
memory if they are resident there.

--
Josh Berkus
Aglio Database Solutions
San Francisco