maria-developers team mailing list archive
-
maria-developers team
-
Mailing list archive
-
Message #12591
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