> Actually, this is already implemented. 

 

> Further, in MariaDB 10.0, there is no fsync() needed in step 3. This is 

> because in case of a crash, XA crash recovery can repeat the step 3 using the 

> information saved in step 1 and 2. So in 10.0, we only need one shared fsync 

> in step 1 plus one shared fsync in step 2. 

 

> If you look in the innodb/xtradb code, you can see this. The prepare step 

> calls trx_prepare_for_mysql() in trx/trx0trx.cc. This calls trx_prepare() 

> which goes to trx_flush_log_if_needed_low() and calls log_write_up_to() in 

> log/log0log.cc. And in log_write_up_to(), you will see the group commit 

> logic. The transaction will wait for any previous fsync to complete; then if 

> it still needs the fsync(), it will fsync not just itself, but also any other 

> transactions that are waiting for fsync. 

 

> There is some description of the removal of fsync() in step 3 here: 

 

>    http://kristiannielsen.livejournal.com/16382.html 

 

> However, the group commit in step 1 has been in the InnoDB code for many 

> years, as far as I know. 

 

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.

 

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.

 

Thanks