maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

Hi, Sujatha!

Could you split this patch, please?

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.

2. Add extra columns.

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?

If you agree, then you'll only need two commits.

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

On Mar 21, Sujatha wrote:
> revision-id: e5fc78f84e3 (mariadb-10.5.2-303-ge5fc78f84e3)
> parent(s): 8b8969929d7
> author: Sujatha <sujatha.sivakumar@xxxxxxxxxxx>
> committer: Sujatha <sujatha.sivakumar@xxxxxxxxxxx>
> timestamp: 2020-11-27 12:59:42 +0530
> message:
> 
> MDEV-20220: Merge 5.7 P_S replication table 'replication_applier_status_by_worker
> 
> Fix:
> ===
> Iterate through rpl_parallel_thread_pool and display slave worker thread
> specific information as part of 'replication_applier_status_by_worker' table.
> 
> ---------------------------------------------------------------------------------
> |Column Name:           |        Description:                                   |
> |-------------------------------------------------------------------------------|
> |                       |                                                       |
> |THREAD_ID              | Thread_Id as displayed in 'performance_schema.threads'|
> |                       | table for thread with name                            |
> |                       | 'thread/sql/rpl_parallel_thread'                      |
> |                       |                                                       |
> |                       | THREAD_ID will be NULL when worker threads are stopped|
> |                       | due to error/force stop                               |
> |                       |                                                       |
> |SERVICE_STATE          | Thread is running or not                              |
> |                       |                                                       |
> |LAST_SEEN_TRANSACTION  | Last GTID executed by worker                          |
> |                       |                                                       |
> |LAST_ERROR_NUMBER      | Last Error that occurred on a particular worker       |
> |                       |                                                       |
> |LAST_ERROR_MESSAGE     | Last error specific message                           |
> |                       |                                                       |
> |LAST_ERROR_TIMESTAMP   | Time stamp of last error                              |
> |                       |                                                       |
> |WORKER_IDLE_TIME       | Total idle time in seconds that the worker thread has |
> |                       | spent waiting for work from SQL thread                |
> |                       |                                                       |
> |LAST_TRANS_RETRY_COUNT | Total number of retries attempted by last transaction |
> ---------------------------------------------------------------------------------
> 
> 
> In case STOP SLAVE is executed worker threads will be gone, hence worker
> threads will be unavailable. Querying the table at this stage will give empty
> rows. To address this case when worker threads are about to stop, due to an
> error or forced stop, create a backup pool and preserve the data which is
> relevant to populate performance schema table. Clear the backup pool upon
> slave start.