简介
主从数据不一致，主要是SQL执行速度慢导致，所以需要开启多线程复制，保证从库并发应用relay-log能力
一般来说2颗32核CPU 128G内存，硬盘HDD，TPS（每秒处理事务的速度）可以达到3万
每个参数都会对应一个表，直接在系统界面可以通过过滤查找到表中的参数
每个参数都会对应一个表，直接在系统界面可以通过过滤查找到表中的参数
优化
slave_parallel_type 指定并发复制的类型
LOGICAL_CLOCK：基于组提交的并发复制 。 依赖主库中commit时间戳，根据last_commit的值判定，如果相同，则认为是同一组的
slave_preserve_commit_order;是否保留事务提交的顺序（默认不保留），做了主从复制和读写分离要设置(简单的话可以不修改)
优化需要修改的部分
slave_parallel_workers
有多少个线程一起工作,可以改为4个
set global slave_parallel_workers=4;
master_info_repository指定存储信息保存方式
多线程复制要改为表形式
master_info_repository指定存储信息保存方式，启用table模式是因为如果在多线程模式下，会频繁更新master.info文件，消耗代价过高，并且此值也不是非常准确，多线程复制要改为表形式 set global master_info_repository='table'; 可以提高数据库本身或者所在主机意外终止之后crash recovery的能力，且可以保证数据一致性。
set global master_info_repository='table';
relay_log_info_file 保存了日志名称（relay-log.info），relay_log_info_repository指定以什么形式保存中继日志，需要改为table
从库修改成表模式：
set global relay_log_info_repository='table';
从库crash时，SQL线程可能还有一部分relay log重放延迟，另外，IO线程的位置也可能正处于一个事务的中间，并不完整，所以必须在从库上启用参数relay-log-recovery=ON，启用该参数之后，从库crash recovery时会清理掉SQL线程未重放完成的relay log，并以SQL线程的位置为准重置掉IO线程的位置重新从主库请求。
如果想修改一个表的存储引擎使用alter table slave_master_info engine="Myisam";
开启slave查看线程列表
show processlist;
下面有四个线程调度器，从库等待主库发送事件，并已经读取到中继日志，正在等待主库的数据更新
为了测试，服务端和客户端写一个循环插入和持续监控数据脚本
服务端
#!/bin/bash
for i in {1..100000};do
mysql -uroot -p123 -e "use abc;insert into students values('a$i');"
done客户端
#!/bin/bash
for i in {1..100000};do
mysql -uroot -p123 -e "use abc;insert into students values('a$i');"
done效果
system lock表示正在工作
发布者：LJH，转发请注明出处：https://www.ljh.cool/6452.html
