Thanks for your response, Andrew.
On Tue, 8 May 2007, Andrew Sullivan wrote:
> On Fri, May 04, 2007 at 08:54:10AM -0600, Joel Dice wrote:
>>
>> My next question is this: what are the dangers of turning fsync off in the
>> context of a high-availablilty cluster using asynchronous replication?
>
> My real question is why you want to turn it off. If you're using a
> battery-backed cache on your disk controller, then fsync ought to be
> pretty close to free. Are you sure that turning it off will deliver
> the benefit you think it will?
You may very well be right. I tend to think in terms of software
solutions, but a hardware solution may be most appropriate here. In any
case, I'm not at all sure this will bring a significant peformance
improvement. I just want to understand the implications before I start
fiddling; if fsync=off is dangerous, it doesn't matter what the
performance benefits may be.
>> on Y. Thus, database corruption on X is irrelevant since our first step
>> is to drop them.
>
> Not if the corruption introduces problems for replication, which is
> indeed possible.
That's exactly what I want to understand. How, exactly, is this possible?
If the danger of fsync is that it may leave the on-disk state of the
database in an inconsistent state after a crash, it would not seem to have
any implications for activity occurring prior to the crash. In
particular, a trigger-based replication system would seem to be immune.
In other words, while there may be ways the master could cause corruption
on the slave, I don't see how they could be related to the fsync setting.
- Joel
