You are using the performance Schema to investigate replication on a slave:
Mysql> SELECT THREAD_ID threads.NAME, SUM (COUNT_STAR) AS Totalcount, SUM
(SUM_TIMER_WAIT) AS Totaltime
FROM performance_schema.events_waits_summary_by_thread_by_event_name
INNER JOIN performance_schema,threads USING (THREAD_ID)
WHERE threads .NAME LIKE ‘thread/sql/slave\-%’
GROUP BY THREAD_ID, threads.NAME;
Assume that all instruments and consumers are enabled and all threads are instrumented.
Which two facts can be concluded from the given output?
A.
At most two schemas are being updated concurrently.
B.
The server needs more cores to use all slave threads.
C.
The slave cannot process the relay log fast enough to use all threads.
D.
The slave is configured with slave_parallel_workers = 4.
Explanation:
C, D
I cannot see the reasoning of C.
Since parallel replication likes to split the activity across slave threads by schema, A seems a more accurate answer, along with D.
A, D
A, a worker can only work on independent elements as schemas(db).
The right answer will be A and D .
MySQL 5.6 introduces a new “multi-threaded slave” feature (aka “parallel replication”) that turns the “slave SQL thread” into a number of distinct threads that each apply events to different schemas.