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