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