![](https://secure.gravatar.com/avatar/99fde0c1dfd216326aae0aff30d493f1.jpg?s=120&d=mm&r=g)
Gordan Bobic via discuss
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.