----- Original Message -----

"Sergei Golubchik (JIRA)" <jira@mariadb.atlassian.net> 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.