maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx> writes:

> 1. Adding status variables for parallel replication.
>
>   http://lists.askmonty.org/pipermail/commits/2015-July/008131.html
>
> This patch adds new status variables that measure the time spent by parallel
> replication worker threads being

After initial tests of the new parallel replication status timers, a bug was
found and some useful refinements discovered. I wrote a patch that
fixes/improves this:

    http://lists.askmonty.org/pipermail/commits/2015-July/008165.html

First, the code for slave_parallel_wait_prior was incomplete. Some cases of
waiting for a prior transaction were incorrectly attributed to
slave_parallel_processing, underestimating the cost of enforcing in-order.

Second, two extra status variables are introduced to better distinguish
different reasons for waiting for a prior transaction. With this patch we
have:

1. slave_parallel_wait_prior. This counts time where a transaction was ready
to commit, but had to wait for a prior transaction to commit first to
enforce correct in-order replication.

2. slave_parallel_wait_retry. This counts the wait that happens when a
transaction deadlocks. (In addition to this, the transaction needs to be
rolled back and re-tried, these are accounted for in
slave_parallel_trx_retry).

3. slave_parallel_wait_dependency. In the optimistic and aggressive modes,
this counts waits done for transaction processing that cannot happen in
parallel. This includes non-transactional updates (MyISAM) and
statement-based replication of temporary tables, which are not safe to
optimistically parallelise. It also includes heuristics in optimistic mode
that avoids parallel replication of transactions that had row lock waits on
the master or that were marked with @@skip_parallel_replication. (It does
not include DDL-induced waits, these are accounted as
slave_parallel_wait_group in optimistic and aggressive modes).

Testing and comments welcomed. I have not been able to do much testing
myself of these so far, and mysql-test-run testing is in its nature hard for
micro-second status timers.

 - Kristian.