maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Giuseppe Maxia <g.maxia@xxxxxxxxx> writes:

> I am looking for:
> * how many workers are used;

The number of workers created is determined by the value of
@@slave_parallel_threads. That many worker threads are in the replication
worker thread pool, shared among all multi-source master connections.

Workers are scheduled by the SQL threads dynamically, depending on what
parallelism is available in the events being read from the relay logs at any
given point in time. Workers for which there is currently no work available
will appear as "Waiting for work from SQL thread" in SHOW PROCESSLIST.

> * what query they are running.

I think this should appear in SHOW PROCESSLIST, same as for the SQL thread in
non-parallel replication.

> * in which schema they are working;

That is not really meaningful? A worker thread can be working in multiple
schemas at the same time (multi-table update...).

The parallel replication feature works like this:

 - On the master, binlog events are marked for whether they can be replicated
   in parallel. Two events can be replication in parallel if 1) their GTID
   events have the same group commit ID (cid=XXX in mysqlbinlog output), or 2)
   if their GTID has different replication domain (first number in the
   GTID=D-S-N tripple), and the slave is operating in GTID mode.

 - On the slave, the SQL thread reads events from the relay log, and
   dynamically schedules the same or a new worker to execute the events so
   read, depending on whether parallelism is possible or not. If the pool of
   threads is exhausted, the SQL thread waits for a worker thread to become
   idle.

So unlike MySQL multi-threaded slave, worker threads in MariaDB have no
identity. Any worker thread can potentially be scheduled to work on any event
from any master connection.

> What can I use to see the status of parallel replication?

Nowhere, really :-(

The parallel replication feature has been basically rushed ruthlessly to
release, with no time taken for any polish like this or other similar
reasonable concerns...

I did briefly think of what could be made available, but I did not come up
with any immediate ideas. The scheduling of parallel replication work really
is very dynamic in nature, just like any other application load. Maybe the
performance schema or something like that could be used, but I am not familiar
with how it works. Suggestions definitely welcome.

Giuseppe, btw, thanks for once again taking the time to look and comment on my
work!

 - Kristian.