maria-developers team mailing list archive
Mailing list archive
Re: a question about group commit
> 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:
> 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.