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
