maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

"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.

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

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?

 - Kristian.