一 简介
1 sql_thread 应用binlog
2 io_thread 复制传递binlog
二 版本
5.5 单线程
5.6 库级别 slave-parallel-type = database
5.7.21 表级别多线程
5.7.21+ 表级别多线程 slave-parallel-type=LOGICAL_CLOCK
行级别多线程 slave-parallel-type=LOGICAL_CLOCK binlog_transaction_dependency_tracking = WRITESET
三 表级别并行复制实现原理
以下阶段是可以进行并行复制的
1 根据两阶段提交协议,事务只要达到了redo的prepare状态,就代表了没有锁冲突
2 处在prepare和commit之间的事务
binlog的改在
1 mysql本身对binlog进行了改造,增加了两个参数 last_committed sequence_number,其中last_committed相同代表着同一时间段内提交的事务是可以被并行执行的
开启并行复制:
从库添加参数
slave-parallel-type=LOGICAL_CLOCK//并行复制
slave-parallel-workers=16 //sql线程数量 推荐 4-8 个
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON //保证relay-log的完整性
改良:从事务确认锁冲突从redo commit阶段提升到了redo prepare,可以应用处在prepare和commit之间的事务
以下参数会影响事务提交的性能,慎重调整,目的是提升并发复制的性能
binlog_group_commit_sync_delay
binlog_group_commit_sync_no_delay
四 行级别复制参数
新增binlog_transaction_dependency_tracking
1 COMMIT_ORDER 根据事务进入prepare和commit阶段进行判断是否可以并行复制
2 WRITESET 根据事务更新的每一行,计算一行hash,然后形成write_set集合.如果没有操作相同的行,hash值是不一样的,可以并发执行=>(唯一性索引名+库名+表名+值)
3 WRITESET_SESSION 在写集合的基础上增加约束,保证按照前后顺序执行
注意: 1 当表无主键或者有外键的话,并行复制会退化为单线程复制
2 行级别复制是在表级别复制的基础上进行进一步计算,所以需要依赖表级别复制所需要的东西
五 总结
演化历史:
1 单线程复制->不同库级别的复制->不同事务级别的复制->基于行级别的复制