> 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
_______________________________________________
Mailing list: https://launchpad.net/~maria-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
