Bug #74765 RPL P_S: move SQL thread status to worker table

• Submitted: 10 Nov 2014 12:54
• Modified: 16 Sep 2015 8:52
• Reporter: Shivji Jha
• Status: Closed
• Category: MySQL Server: Replication
• Severity: S3 (Non-critical)
• Version: 5.7.2
• OS: Any
• CPU Architecture: Any

[10 Nov 2014 12:54] Shivji Jha

Description:
WL#3656 introduced performance_schema tables to monitor replication configuration and status.
1) The status of coordinator thread was reported as part of the table replication_execute_status_by_coordinator
2) The status of worker threads is reported in the table replication_execute_status_by_worker.
3) The status of SQL thread (single threaded applier case) is reported as part of replication_execute_status_by_coordinator

The bug report requests that (3) be changed so that SQL thread status is also reported via worker table.
This has following benefits:
1) To see the applier status a monitoring tool does not have to move between coordinator and worker table based on whether
   single threaded applier or MTS is being used.
2) We have applier status and stats in worker table which make sense for SQL thread too.
3) In future we could have scheduler stats in coordinator table which does not make sense for SQL thread so they have to be always empty.

How to repeat:
See the description section.

Suggested fix:
Move status of SQL thread to worker table.

[16 Sep 2015 8:52] Jon Stephens

Documented the feature change in the 5.7.9 and 5.8.0 changelogs, as follows:

    When using a single-threaded slave, the status of the applier
    thread is now reported as part of the
    replication_applier_status_by_worker table, instead of
    replication_applier_status_by_coordinator. This means that
    replication_applier_status_by_coordinator is now empty when
    using a single-threaded slave; it should be noted that such
    reporting for multi-threaded slaves has not been changed, and
    continues to be shown in this table.

Also updated the descriptions of these tables in the Manual.

Closed.