Details
-
Task
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
None
-
10.1.21, 10.1.29, 10.1.30, 10.1.32
Description
Hi,
from the documentation [1], I can read:
Non-transactional DML and DDL is not safe to optimistically apply in parallel, as it cannot be rolled back in case of conflicts. Thus, in optimistic mode, non-transactional (such as MyISAM) updates are not applied in parallel with earlier events (it is however possible to apply a MyISAM update in parallel with a later InnoDB update). DDL statements are not applied in parallel with any other transactions, earlier or later.
[1]: https://mariadb.com/kb/en/mariadb/parallel-replication/
It would be very helpful to have slave-side counters (statuses) for both of those non-transnational updates and DDL statements. This would allow to see if optimistic parallel replication is slowed-down by non-transnational updates and DDL statements.
Many thanks,
JFG
Attachments
Activity
Review notes are mailed to commits@ list. The patch requires a minor work to address them.
julien.fritsch, Actually I thought that we need this 10.3 rc , so I have set the issue to blocker.
As this should not introduce any risk of regression, maybe this can also be back-ported to 10.2.
Hi jeanfrancois.gagne, although you are right, but 10.2 is ga
I am not sure whether we can backport this in 10.2 or not
I suspect that adding new columns to SHOW MASTER INFO might break existing applications, so it's somewhat reckless to do it in a GA version.
Thinking about this a little more, those should not be global statuses but be property for the replication channel. This should be the same for slave_retried_transactions (not being a global status, but be a property of a replication channel). Having this information at the channel level instead of the global statues would allow to be able to monitor multi-source replication in a better way.
At the same time, it would probably be interesting to add more information for replication applier monitoring. I am thinking about the slave equivalent of Binlog_commits and Binlog_group_commits. Those 2 statuses allow to monitor transaction grouping on the master. Having the same thing for the SQL_THREAD (which transaction grouping is the SQL_THREAD seeing from the master) would allow to be able to have an holistic view on the slave.