文章目录
-
- 架构设计
- 复制机制
-
- 复制流程
- binlog格式
- 主从复制模式
- 多线程复制提高从库应用速度
-
- 主备延迟
- 从库并行复制策略
-
- 按表分发worker
- 按行分发worker
- 按库分发worker
- [MariaDB 并行复制策略](#MariaDB 并行复制策略)
- [mysql 优化 MariaDB 并行复制策略](#mysql 优化 MariaDB 并行复制策略)
- 负载均衡
- 数据可靠性
- 故障检测与恢复
架构设计
innodb集群：一主一备、双主、一主多从
双主架构
循环复制问题
两个主节点，你复制我的日志，我复制你的日志，但怎么区分出来我复制你的日志是你执行了的的新日志，不是我传给你的我的日志呢（我不需要复制我的日志，循环复制）
日志的执行流程：
- 节点A更新事务，binlog中记录A的日志和A的server id;
- 传给B执行后，B生成的binlog中的server id保持A的server id // B自己的新日志写入binlog是server id是B的
- 再传给A时，A发现是自己的就不执行了
如何不同步一个事务
B想执行一个事务，比如加个索引，但不同步给B执行。可以考虑的方案：
-
在A上stop slave
-
在B上执行语句。注意：这里不需要关闭binlog
-
执行完了，查出这个事务的GTID
-
到A上跳过这个GTID
set GTID_NEXT="server_uuid_of_B:gno123" begin; commit; // 提交空事务，跳过server_uuid_of_B:gno123 set gtid_next=automatic; // 恢复 start slave;
复制机制
- 主从切换，数据同步：GTID全局事务标识、位点、延迟时间=0 // 详见故障检测与恢复
- 多线程复制提高从库应用速度：relay log中转日志给多个work并发复制
- 延迟复制应对误操作场景：主库误删数据，快速同步给从库，又芭比Q了。准备一个从库延迟复制，抵御误删风险
复制流程
binlog格式
- binlog=statement 直接复制语句。日志量少，可读性强
- binlog=row 复制变更前后的数据和操作。日志量大，可用于恢复数据
- binlog=mixed 不引起主备不一致的语句复制sql，可能引起主备不一致的复制具体语句，比如delete ... limit 1 复制原语句在主备上删除的行可能不同，所以复制变更前后的数据和操作
主从复制模式
- 异步复制：主库复制完就返回客户端ok，异步进行binlog同步
- 半同步复制（semi-sync）：至少一个从库确认后返回。不然主库完成后通过客户端ok就挂了，那没有从库有数据就芭比Q了。等一个从库确认了再通知客户端成功，不然就认为失败。
多线程复制提高从库应用速度
主备延迟
原因
- 从库机器性能比主库差
- 从库读压力大 => 可以考虑加从库
- 大事务，比如大的删除事务 主库执行10分钟然后发到从库去执行就会有延迟；大表的DDL操作，比如加个字段
- 从库relay_log单线程，主库事务是并发执行的
解决方案
-
强制走主库
关键业务查询显示指定走主库
-
sleep一会儿，睡多睡少了都是事儿
-
等 seconds_behind_master = 0
-
等主库位点方案
-
等GTID方案
在从库上等这个事务（不是等所有延迟事务都同步完成）执行，等x秒，等到就返回；没等到（超时），就拒绝服务或者返回主库；
如果存在大量返回主库的，需要主库做好限流，别被打崩；
配合semi-sync方案（半同步复制）方案使用
从库并行复制策略
原则：
- 同一个事务不能被拆开，必须放在一个worker中
- 不能造成更新覆盖。更新同一行的两个事务必须在一个worker中
按表分发worker
每个worker维护一个hash表[库名-表名]：修改这个表的正在执行的事务list
如果一个要执行的事务和多个worker冲突，就阻塞等待只剩一个冲突worker放在这个worker中；修改热点表时，就容易变成单线程。
按行分发worker
每个worker维护一个hash表[库民-表名-唯一键名-唯一键值]
按行分发要求binlog必须是row模式
按行分发比按表分发粒度细，并发度高，但计算、维护hash成本也更高
大事务不适合按行分发worker，会有很大一个hash表，大事务要单线程执行，等执行完了再恢复并行能力
按库分发worker
比按表、行都快，方便；但你就一个库那就没有并行复制了
MariaDB 并行复制策略
想要从库并发，思考如何直接利用主库的并发校验结果 => group commit 组提交。一组提交的事务一定不是冲突的，能并发执行。
不过有个问题：一组事务这个粒度很大，而且同时只有一组事务committing完成在从库复制，要等这组复制完再进行下一组的复制，有空白期，并发能力不够
mysql 优化 MariaDB 并行复制策略
取事务状态再提前一点，同时处于redo log prepare状态的任务（// 已经写binlog但还没commit）就是可以并发执行的了；
同时，控制binlog_group_commit_sync_delay、binlog_group_commit_sync_no_delay_count 多攒点binlog一起提交，通过延迟，增加并发量
配置binlog-transaction-dependency-tracking
COMMIT_ORDER： 根据同时进入prepare和commit来判断是否可以并行复制
WRITESET：按行分发，计算hash。对于事务涉及更新的每一行，计算这一行的hash，得到writeset集合。如果两个事务writeset没有交集，就能并行执行
WRITESET_SESSION：在writeset基础上，加个约束：在主库同一个线程上先后执行的两个事务，在备库上也要保证相同的先后顺序
负载均衡
读写分离、连接池、多活部署
数据可靠性
持久性保证：WAL机制、redo log、binlog
崩溃恢复：redo 回放，undo log回滚（比如长事务回滚中崩溃了，重启了还需要继续回滚）