MySQL 主从复制的过程

MySQL 主从复制，其线程和过程分析

Master ->Slave IO_Thread (单线程)->Slave Relay log -> Slave SQL_Thread (单线程，每次等待所有Worker线程处理完毕之后才重新拉取新binlog)->Slave_Coordinator - >Slave_Worker (parallel_worker)，假设parallel_worker = 8，其中一个是大DDL，其余7个dml语句必须是等待这个DDL执行完成后，才会继续下一轮的sql_thread回放应用relaylog。所以结论：在MySQL中，应当尽量避免大事务，尤其是在生产环境主从架构中，大事务会严重影响其MTS中slave_worker并行回放的性能，导致slave_worker线程等待。

– Coordinator //协调者、统筹者、监控
– Worker //工作线程，对应的是slave_parallel_worker 参数设置

– 除去show slave status\G命令无法提供足够的信息排查复制延迟问题，可通过了解进程处于什么活动状态或正在等待中
1、查看MySQL的线程表

SELECT name, processlist_state, processlist_time FROM performance_schema.threads WHERE name LIKE '%slave%';

2、查看replication_connection_status

SELECT * FROM performance_schema.replication_connection_status;

3、查看replication_applier_status_by_worker

SELECT * FROM performance_schema.replication_applier_status_by_worker;

##MySQL主从延迟问题分析和处理的总结

一、主要参数配置

[主库设置]
binlog_group_commit_sync_delay          
binlog_group_commit_sync_no_delay_count 

[从库设置]
slave_parallel_type                     
slave_parallel_workers                  
slave_pending_jobs_size_max             
slave_preserve_commit_order             
slave_rows_search_algorithms    

replica_pending_jobs_size_max/slave_pending_jobs_size_max
max_allowed_packet  

innodb_flush_log_at_trx_commit
sync_binlog