maria-developers team mailing list archive

[Daniel Black <daniel.black@xxxxxxxxxxxxx>]

----- Original Message -----
> "Sergei Golubchik (JIRA)" <jira@xxxxxxxxxxxxxxxxxxxxx> writes:
> 
> >>                 Key: MDEV-7557
> >>                 URL: https://mariadb.atlassian.net/browse/MDEV-7557
> 
> >> In optimistic parallel replication (MDEV-6676), we speculatively apply
> >> transactions in parallel, even if they might conflict. If too many
> >> conflicts
> >> happen, excessive retry might degrade performance.
> >> The DBA needs some way to monitor for such problems. One good way would
> >> seem
> >> to have an option to add to the slow query log any transactions that were
> >> retried due to parallel replication conflicts. Possibly with extra
> >> information  such as duration of transaction and similar.

great feature request.

> > I'm not sure that slow log is a good match for this kind of events

It only makes it hard if the format is incompatible with mysqldumpslow

> Right. So do you have a suggestion for a better way?
> 
> I was thinking on --log-queries-not-using-indexes, which similarly uses the
> slow query log to expose certain kinds of problematic queries. So queries
> that
> cause deadlocks could be another useful filter for the slow log (it should
> then probably be for all queries that deadlock, not just replication
> queries).
> 
> In non-parallel replication, we put deadlock errors as warnings in the error
> log. But I disabled that for parallel replication. In non-parallel
> replication, you normally do not expect any deadlocks (since there is only
> one
> thread, how can it deadlock?). But in parallel replication, deadlocks are
> generally unavoidable, and not harmful. And DBAs do not like noise in the
> error logs that does not indicate a problem and cannot be removed.
> 
> One option might be to log deadlocks as INFO level in the error log, and then
> users can temporarily raise verbosity level to see them?
> 
> Another option could be to add an option to enable/disable logging deadlocks
> as warnings in parallel replication. (Though probably you will think as me,
> that this feels a bit like too ad-hoc an option to add.)
> 
> Any other ideas?

Use a variable long_rollback_time as the trigger. The query time is generally unavoidable
however if the rollback time (for all retries) for the queries starts to rise that's when you want to notice.

The log should show the number of rollbacks as well. I'd be happy if this included application rollbacks too but isn't essential.

Slow query log I think is a reasonable fit as log-slow-verbosity=query_plan,explain 
gives you a fairly good idea as to which indexes are locked.


-- 
Daniel Black, Engineer @ Open Query (http://openquery.com.au)
Remote expertise & maintenance for MySQL/MariaDB server environments.