maria-developers team mailing list archive

["nanyi607rao" <nanyi607rao@xxxxxxxxx>]

> 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