← Back to team overview

maria-developers team mailing list archive

Re: e5fc78f84e3: MDEV-20220: Merge 5.7 P_S replication table 'replication_applier_status_by_worker


Hi, Sujatha!

On Mar 22, sujatha wrote:
> On 21/03/21 8:21 pm, Sergei Golubchik wrote:
> > Hi, Sujatha!
> >
> > Could you split this patch, please?
> Sure.
> >
> > 1. Just add replication_applier_status_by_worker table. With
> >     CHANNEL_NAME column and (perhaps, not sure if it applies) with
> >     WORKER_ID column. Without extra columns and backup.
> Reason for not including CHANNEL_NAME and WORKER_ID is, multi-source 
> based parallel replication is bit different in MySQL.
> Please find the following information.
> ==> https://dev.mysql.com/doc/refman/5.7/en/replication-channels.html
>          A multi-source replica can also be set up as a multi-threaded 
> replica, by setting the slave_parallel_workers system variable to a 
> value greater than 0. When you do this on a multi-source replica, each 
> channel on the replica         has the specified number of applier 
> threads, plus a coordinator thread to manage them. You cannot configure 
> the number of applier threads for individual channels.
> In case of MySQL, worker threads are dedicated to particular channel.
> In MariaDB "The pool of replication worker threads is shared among all 
> multi-source master connections, and among all replication domains that 
> can replicate in parallel using out-of-order".
> Because of this I didn't include CHANNEL_NAME. In MariaDB Slave_worker 
> thread's don't have WORKER_ID they only have 'thread_id'.

Okay, thanks

May be it'd still make sense to keep CHANNEL_NAME, for the connection
name the worker is currently working for? Even if the pool is shared, at
any given moment in time the worker can apply a transaction only from
some specific connection, right?

> > 3. Add backup.
> >
> > With these three commits you'll have exactly the same diff as now, just
> > split (and with CHANNEL_NAME column).
> >
> > But really, I wonder whether this backup functionality is needed at all?
> > In MySQL there is persistent information about these workers, it doesn't
> > go away when they're stopped, it's stored persistently in a table,
> > indexed by worker_id. If we don't have anything persistent like that and
> > all workers completely disappear into oblivion, then, may be,
> > replication_applier_status_by_worker should not show anything when they
> > aren't running?
> MySQL doesn't persist the worker information in a table. When workers
> are stopped due to an error or STOP SLAVE,  worker information is
> copied(backup) and it is retained till next START SLAVE. Please find
> following snippets.

Well, there is mysql.slave_worker_info, it's persistent.

VP of MariaDB Server Engineering
and security@xxxxxxxxxxx

Follow ups