Kristian Nielsen <knielsen@knielsen-hq.org> 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.