← 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:
> >>> 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.
..
> >> 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?
> 
> Sure. The 'Connection_Name' can be printed.

Thanks. But keep the CHANNEL_NAME column name for consistency. In other
P_S tables CHANNEL_NAME column is used to show the connection name.

> >> 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.
> Yes, you are right `mysql.slave_worker_info` persists data, for server
> internal usage purpose.

I see, thanks. Then, indeed, we should do this backup-for-PS thing too.

Regards,
Sergei
VP of MariaDB Server Engineering
and security@xxxxxxxxxxx


References