maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

"nanyi607rao" <nanyi607rao@xxxxxxxxx> writes:

> yeah, I got it. InnoDB/xtradb group commit indeed reduce fsync() called
> times in prepare step, but it could do more than one fsync() for a group of
> transactions in binlog group commit to be durable in prepare step.

Ah, yes, now I see, I had forgotten about this.
Yes, you are right, it is very likely that the transactions that are group
committed together in the binlog will need more than one fsync in the prepare
step.

> what I think is it only to make sure that a group of transactions writing to
> binlog has been flushed to innodb/xtradb redolog. so how about don't flush
> redolog in prepare(), insteadly let leader thread to flush innodb/xtradb
> redolog to latest lsn just before it begin to write follower transactions
> and itself to binlog. that only need one fsync() for a group of transactions
> completed prepare step to flush to redolog.

I think it is an interesting idea. It should not be too hard to implement a
prototype, and then it would be interesting to run some benchmarks and see
what effect it can have.

It is hard to predict if it will be a win in all cases - one can imagine some
specific scenarios where a slowdown could occur, but such cases may or may not
be likely to turn up in practise, it's hard to tell without testing.

But it seems likely that it could improve performance in many or even most
cases.

(This problem was actually something that bothered me a bit when I originally
implemented group commit, but I did not so far think much on how to avoid
it. So I am happy to see this suggestion.)

Thanks,

 - Kristian.