Gordan Bobic via discuss <[email protected]> writes: > That would still leave the edge case of a few seconds after it does > eventually write the checkpoint, would it not? I am effectively > looking at a case of "never write a checkpoint".
Yes. I'm thinking that Marko's suggestion to clear the newest checkpoint (not both of them) would eliminate this edge case (with all of the caveats that Marko mentioned). > The objective is to gain a bit of performance on the master node where > being a few seconds behind after a dirty shutdown is not a palatable > option. But doesn't InnoDB already handle this by itself? That's the whole point of the write-ahead log and checkpointing. Database operations only need to wait for the durable write of redo log records. Durable write of buffer pool pages happens in the background, nothing needs to wait for it (except checkpointing, which shouldn't stall things as long as the redo log is sufficiently large). So where do you gain the performance with this idea? Don't get me wrong, I think it's cool to push performace to the limits (and beyond). I'm just curious what the mechanism would be that would make this increase performance over what the write-ahead log / checkpointing already achieves. What is the storage you're using, how does it improve the page flushing internally over what InnoDB itself can achieve? - Kristian. _______________________________________________ discuss mailing list -- [email protected] To unsubscribe send an email to [email protected]
