网站设计色板优化最狠的手机优化软件

架构设计

innodb集群：一主一备、双主、一主多从

双主架构

循环复制问题

两个主节点，你复制我的日志，我复制你的日志，但怎么区分出来我复制你的日志是你执行了的的新日志，不是我传给你的我的日志呢（我不需要复制我的日志，循环复制）

日志的执行流程：

• 节点A更新事务，binlog中记录A的日志和A的server id;
• 传给B执行后，B生成的binlog中的server id保持A的server id // B自己的新日志写入binlog是server id是B的
• 再传给A时，A发现是自己的就不执行了

如何不同步一个事务

B想执行一个事务，比如加个索引，但不同步给B执行。可以考虑的方案：

1. 在A上stop slave

2. 在B上执行语句。注意：这里不需要关闭binlog

3. 执行完了，查出这个事务的GTID

4. 到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回滚（比如长事务回滚中崩溃了，重启了还需要继续回滚）

故障检测与恢复

mysql 故障检测与处理-CSDN博客