Diagnosing Slow Master Commit Performance in MySQL Semi‑Synchronous Replication

Problem: In MySQL semi‑synchronous replication, a slow slave can reduce the master’s commit throughput. When using a one‑master‑multiple‑slave semi‑sync architecture, the question is how to determine which slave is causing the master’s commit slowdown.

Experiment: Using dbdeployer a one‑master‑two‑slave semi‑sync cluster was created. Load was applied to the master, and strace was used to artificially slow down slave 2. Because of the semi‑sync protocol, the throttled slave 2 reduced the master’s commit performance.

Diagnosis: The semi‑sync plugin’s log level was increased to 16, and the master’s error log was examined. The log showed many “semi‑sync block” messages, with the last ACK coming from server_id 300, which corresponds to slave 2. After the investigation the log level was restored.

Conclusion: The semi‑sync plugin does not expose a convenient way to pinpoint the lagging slave, but by enabling detailed debug logging one can see which slave’s ACK is the last to arrive and thus identify the bottleneck. Users should limit the duration of this logging to avoid excessive disk usage.